Simple Cross-Platform File Sharing with Chungles
rammerhammer writes "Sharing files amongst different platforms has most always resulted in using samba -- a program based around the windows file sharing protocol. Chungles aims to provide a nice, graphical, easy configurable file sharing alternative. It's written in Java, uses SWT for the UI, and JmDNS (Rendezvous/ZeroConf/Bonjour) for discovery of computers running Chungles."
This looks like a great idea, but the one thing that it seems to lack is to actually work on files on the remote computer. You can transfer files, which is good, but working from a shared volume has a lot of benefits. Also, speed of transfer is something I'd like to see compared (I could test it, but I'm in for a busy morning and should stop slashdotting unless I lie down.)
I am, and always will be, an idiot. Karma: Coma (mostly effected by
In KDE 3.4 (may have appeared in previous versions, not sure) there is a protocol "fish://" that uses ssh. KDE treats it like a regular konq window and you can copy and move files around. Since it works over ssh it's already popular and easy to set up. Another nice trick they've done is you can open a text file from the remote computer, edit, and when you click save it saves it back to the remote computer.
It's easy to use and integrates well into the rest of KDE.
From the Chungles web site: "It's a file-sharing program for local networks that runs on any platform."
Chungles uses SWT instead of Swing. SWT being available on a fewer platforms than Swing, Chungles is even less portable than a pure Java application.
Don't take me wrong: I love SWT but it is definitely not an option if we want to make an application available on as many platforms as possible.
Because old ideas magically become new and better when you implement them in java.
Badass Resumes
A java program is still a separate program, and there's the obnoxious java license to worry about too. I find samba really nice to use, so much that I even use it for nix-to-nix transfers. And if you don't like it there's always http, open protocol with tiny servers and clients available for every OS (far more than the JRE runs on, in fact. And I think samba has been ported to more systems than JRE)
I am trolling
9p has been around for 15 years and reference code is even Open Source these days.
v9fs on sourceforge for Linux alows mounting remote 9p servers and u9fs is a 9p server for other unix likes.
I use plan9 to edit files on my hosted Linux / FreeBSD / OpenBSD boxes at the co-lo and on the LAN. plan9 usefully mounts the remote file system into my file tree so one can grep sed awk cut join etc. as normal as though the files were local.
Excuse me but I must just say one thing : fuck java, fucking fuck off and die
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
... it's called chungles.
...but it's called chungles. It could be exactly what I'm looking for. But it's called chungles. You've maybe even read my posts, which I've written several times, about how naming shouldn't be a barrier to acceptance, that a PHB who dismisses a product by its name alone probably wasn't serious about it, that the names are whimsy but the product should be evaluated on its merits...
.
I mean, it's useful
But it's called chungles
My boss is very much not a PHB, and is very easy going and technically oriented. But I am not recommending to him or my co-workers that they install something named chungles.
I have my limits as well.
I am no longer wasting my time with slashdot
I use saft, the simple asynchronous file transfer system. I don't know if it has a windows implementation, but it's great for sharing files with someone else directly.
Far far better is SFS, the self-certifying filesystem. It's more trouble to setup (unless you use Debian) but it allows you to create a secure NFS mount that can safely be mounted and used across the internet.
I've used it in the past to give read-only anonymous access to a directory, and I could still fly around the world and securely mount the SFS share somewhere else. You probably don't want to mount an SFS share on insecure hardware that might have a keylogger, but it's a great way to have access to all your source code (and research papers in my case) from a friends house in another country.
Shae Erisson - ScannedInAvian.com
You must be new here. The choice of programming language to use on a certain project depends entirely on the reaction you want from Slashdot. This is the key, as there are absolutely no other important factors that affect the choice of programming language. That's right, none. Certainly, when a group is trying to decide on what language to use for a project, there will be all this talk about what a certain language provides, available implementations for the target platform, programming skills of the group, etc. Do not fall for this malarky. Like communism, this is just a red herring. Because every language is simple, does everything, and is available on every platform, the only reason to pick one language over another is how it will be received by the Slashdot community.
To help you pick a language based on the Slashdot reaction you wish to invoke, I have compiled this handy list:
- Ambivalence: C
- Ennui: C++
- Hatred: C# (.NET)
- Ebullience: C# (Mono)
- Depression: FORTRAN
- Apathy: Ada
- Elitism: Lisp
- Paranoia: Scheme
- Confusion: Prolog
- Nostalgia: 6502 Assembly
- Nausea: 386 Assembly
- Silence: Sh
- Testiness: Tcl
- Puerileness: Ruby
- Blindness: Perl
- Laughter: VB
- Ecstasy: Python
- Ejaculation: PHP
- Total Protonic Reversal: COBOL
- Captious Whining: Java
So there you have it! You should probably print this out now and have it laminated so it will be handy when you need to pick a language for your next project.Show me on the doll where his noodly appendage touched you.