So, tried something different: CygWin's rsync, the swiss army knife for backups, and related stuff. In other words, I am using the command
rsync -a -r --progress
Runs with 30MB per second (50% faster than native Windows copying). And is reentrant...
Rantings of an aging, notorious coder.
mkdir /home/username/sharedfolder sudo mount -t vmhgfs -o uid=1000,gid=1000 .host:sharename /home/username/sharedfolder
# Display a list of all shared folders:# Note, that it includes a share called "sharedfolder".
His name, however, continues to be sent in the so-called Overhead of the clacks. The full message is "GNU John Dearheart", where the G means, that the message should be passed on, the N means "Not Logged" and the U that it should be turned around at the end of the line. So as the name "John Dearheart" keeps going up and down the line, this tradition applies a kind of immortality as "a man is not dead while his name is still spoken".This means, we'll be celebrating "Being childish day" today, by adding the HTTP Header
public void doFilter(ServletRequest pReq, ServletResponse pRes,
FilterChain pChain) throws IOException,
ServletException {
if (pRes instanceof HttpServletResponse) {
final HttpServletResponse res = (HttpServletResponse) pRes;
res.addHeader("X-Clacks-Overhead", "GNU-Terry-Pratchett");
}
pChain.doFilter(pReq, pRes);
}
ClacksOverheadFilter
com.github.jochenw.clacksov.ClacksOverheadFilter
ClacksOverheadFilter
*
sudo yum repolist allOops, you need a terminal window to do that. That's no problem if you are running KDE or any other desktop that you are used to. If it's GNOME 3, and you are not, here's what to do: Press, and release, the "Windows" key. (No, this is still not Windows, but anyways. If it helps, call it the "Linux" key.) Press, and release, the following keys, in that order: "t", "e", "r", "m", and Enter. At that point, a GNOME Terminal window should appear. (Or, in theory, any other desktop application containing the word "term". However, you had no chance to install "xterm" do far. :-) Using the command
sudo yum vi /etc/yum.repos.d/centos7-prerelease.repocreate a new file with the following contents:
[centos7-prerelease] name=CentOS 7 Prerelease url=http://buildlogs.centos.org/centos/7/os/x86_64-20140614/ enabled=1 priority=1 gpgcheck=0And now (I am not avoiding any flame wars today :-) you can do
sudo yum install emacs emacs-nox gcc make binutils kernel-headersA final note on the VMware tools: Anaconda did automatically install "open-vm-tools-desktop". So, mouse integration, copy and paste, etc. worked immediately for me. No need for a seprate installation.
git checkout https://github.com/torvalds/linux.gitWhat are the odds, that this command will run faster on the Linux VM than on the Windows hosts. I'd bet. And I'd win. (It's true: Linux Git on the emulated hardware wins against Windows Git on the raw iron.) Btw, for an even more convincing example, try "git svn checkout".) This week, I decided to waste some time to think about the issue: How do I get my build system on Windows as fast as on Linux. First, let's identify the guilty party: It's none other than... (drum roll) NTFS! I'm not making this up: Others are quite aware of the problem. See, for example, this page. A Google search for "ntfs performance many small files" returns about 168000 hits. So, let's state this as a fact: NTFS behaves extremely poor when dealing with lots of small files. But that's exactly, what a build system is all about. Let's take a typical example:
public interface IVFS { OutputStream createFile(String pPath) throws IOException; void close() throws IOException; }For any source file (45941 files) the method createFile is invoked, the file is copied intoo the OutputStream, and the stream is closed. Finally, the method IVFS.close() is invoked. Here's my programs output:
Linux Kernel Extraction, NullVFS: 4159 Linux Kernel Extraction, SimpleVFS: 1740044 Linux Kernel Extraction, MapVFS: 78134The three implementations are:
$ touch aux.c jwi@MCJWI01 /c/Users/jwi/workspace/afw-vfs $ ls -al aux.c -rw-r--r--+ 1 jwi Domain Users 0 May 1 16:02 aux.c jwi@MCJWI01 /c/Users/jwi/workspace/afw-vfsSo, our JDK programmer has managed to move the problem with the "aux.c" file name from Windows to the JDK. Thanks, a lot!
$ sudo yum list | grep openjdk java-1.6.0-openjdk.x86_64 1:1.6.0.0-59.1.10.3.fc16 installed java-1.6.0-openjdk-devel.x86_64 1:1.6.0.0-59.1.10.3.fc16 installed java-1.6.0-openjdk-javadoc.x86_64 1:1.6.0.0-59.1.10.3.fc16 installed java-1.7.0-openjdk.x86_64 1:1.7.0.60-2.4.2.0.fc19 @updates java-1.7.0-openjdk-demo.x86_64 1:1.7.0.60-2.4.2.0.fc19 @updates java-1.7.0-openjdk-devel.x86_64 1:1.7.0.60-2.4.2.0.fc19 @updates java-1.7.0-openjdk-javadoc.noarch 1:1.7.0.60-2.4.2.0.fc19 @updates java-1.7.0-openjdk-src.x86_64 1:1.7.0.60-2.4.2.0.fc19 @updates java-1.7.0-openjdk-accessibility.x86_64 java-1.8.0-openjdk.i686 1:1.8.0.0-0.9.b89.fc19 updates java-1.8.0-openjdk.x86_64 1:1.8.0.0-0.9.b89.fc19 updates java-1.8.0-openjdk-demo.x86_64 1:1.8.0.0-0.9.b89.fc19 updates java-1.8.0-openjdk-devel.i686 1:1.8.0.0-0.9.b89.fc19 updates java-1.8.0-openjdk-devel.x86_64 1:1.8.0.0-0.9.b89.fc19 updates java-1.8.0-openjdk-javadoc.noarch 1:1.8.0.0-0.9.b89.fc19 updates java-1.8.0-openjdk-src.x86_64 1:1.8.0.0-0.9.b89.fc19 updatesThe same goes for Fedora 18 and 17, btw. (I'll skip the output here. Note, that processing these commands will take some time, as yum will download the complete repository metadata for the respective version.
$ sudo yum --releasever=17 list | grep openjdk $ sudo yum --releasever=18 list | grep openjdkHowever, Java 6 is available for Fedora 16!
$ export http_proxy=MY_PROXY_URL, for example http://my.proxy.server:8080 $ wget wget http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/16/Fedora/x86_64/os/Packages/java-1.6.0-openjdk-1.6.0.0-59.1.10.3.fc16.x86_64.rpm $ wget http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/16/Fedora/x86_64/os/Packages/java-1.6.0-openjdk-devel-1.6.0.0-59.1.10.3.fc16.x86_64.rpm $ wget http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/16/Fedora/x86_64/os/Packages/java-1.6.0-openjdk-javadoc-1.6.0.0-59.1.10.3.fc16.x86_64.rpmNow, my first (and preferred) attempt to install these would be
$ sudo yum localinstall --obsoletes java-1.6.0-openjdk*which fails, due to the following error message:
error: Failed dependencies: java-1.6.0-openjdk is obsoleted by (installed) java-1.7.0-openjdk-1:1.7.0.60-2.4.2.0.fc19.x86_64 java-1.6.0-openjdk-devel is obsoleted by (installed) java-1.7.0-openjdk-1:1.7.0.60-2.4.2.0.fc19.x86_64 java-1.6.0-openjdk-javadoc is obsoleted by (installed) java-1.7.0-openjdk-1:1.7.0.60-2.4.2.0.fc19.x86_64(Please contact me, if you have an idea on how to get rid of these!) Fortunately, there's another possibility, which does the job quite neatly:
$ sudo rpm --nodeps -i java-1.6.0-openjdk*If you're an Eclipse user, the JDK can now be found in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/