Insync has a small GUI that you can open that shows you, visually, what files are being synced. I've used it for years now with no complaint between several computers (desktop and laptop) and the files are just there. The bigger ones take a little longer but with 1gbit network it is almost instantaneous.

There is teamviewer which is a similar option as well, and free for non commercial use.

... if you write a piece of code for a project with a specific functionality that is requested and you finish it and the requested functionality for your piece of code has changed, then you have still written the code that was "asked" for.

If it is a problem with the fact that time changes, code changes, goals changes then fork the project, otherwise keep up the spirit and evolve with the project.

I don't think I've ever worked on a project where the end goal has been the same for anybody, small differences here and there and then the never ending "if we have this feataure, then we can do ..." and so on and then the projects evolve beyond the initial project goal... aka. "evolution".

I can't see what the problem is, yes the DBI's life in wine is a rather difficult thing, but the changes of the overall project be it open source or in the future a more commercially oriented organizational structure and environment, then it is still a piece of code in the project that is needed, from what I can understand. Commercial or not, then wine is a good thing and if the chief maintainer goes commercial, then a lot of developers would most likely abandon the project and move on to other tings or as you say fork the project.

Either way, I don't see the problem as being the maintainer, but rather an piece of evolutionary jump for the project. Wine has been very slow to gain momentum and for me the only program I use it for (or rather will) is VMWare Infrastructure Client, but not being a great hacker with the knowledge to hack wine, I'm waiting, more or less patiently :-) I'll gladly pay for wine (or the the possible fork) when it is supported to get rid of a virtual machine just to run that program.

As it is now, I think it is way out in the future, open source or commercial, so either way the problem for me seems more like an evlutionary bump in the road than a time for a fork.

Is it early monday morning and I've missed the point or is it a minor problem?

Somebody might be able to ensure some sort or of public/private keypair cryptology between the SMTP servers to encrypt the message-id or what other information is used to say "this is the message you can fetch for user X". Possibly a publicly signed key, somewhat like the current SSL-certificate signing.

That way the only "change" to the SMTP protocol would be

  - fetching the message from the receiving SMTP server that would normally just receive everything
  - some encryption based on the MX record validity/certificicate signing to ensure the correct receiver fetches the mail

I don't think that it would be a big issue or problem to implement.

Well either sign/encrypt the message with the receivers key or just make the SMTP protocol fetch the mail from the MX server that is says it comes from, this will make sure that approx. 90% of all spam will never reach you inbox since they need to have a valid MX record for the mail to orriginate from.

To day the SMTP protocol goes like this:

userA@sub1.example.com sends a mail from a spoofing SMTP server at some arbitrary IP address to someuser@sub2.example.com, the sub2 SMTP server receives everything from SMTP server from the IP address, "thinking" it is from SMTP at sub1 and puts it in the inbox of someuser@sub2.example.com.

If it was "reverse"-SMTP then it would be like this:

The spoofing SMTP sever at some IP sends a mail for userA@sub1.example.com to someuser@sub2.example.com.
The SMTP server at sub2 gets the inital handshake from the spoofing SMPT IP server and then, according to the senders email address eg. the "From:" tag, contacts the MX SMTP server for that email address to fetch the actual mail.
Since the SMTP server for sub1 does not have the mail that is being sent by the spoofing SMTP server, the SMTP transaction is dropped and the mail never reaches the inbox of someuser@sub2.example.com.

Simple solution to a major problem. No valid MX record for the spoofed email disables the spammer from sending a spoofed email.

It will make it easier to track down spammers since they need an actual domain with an MX record, but it does not, however, solve the problem with fake domain registrations for MX records or hacked DNS records (I'm thinking demographic information (name, address, contact information etc.) But as I understand then work is in progress to make this better... or perhaps not, might just be a dream I had :-)

I never got that ZZ or :wq thing that I see a lot of coworkes use? I always use :w when I've made or finished a sentence and :x to quit and save. Rarely the :q! option. I think it comes from the old unstable network days at the dorm in the late '90... I must be getting old or something like that:x

Don't take this the wrong way, but I laughed out loud when I read you comment, I feel the same way about the MC editor (and any other for that matter :w appears often when I'm in a GUI program). CLI + VI(M) and you have all you need. Gnome/KDE is only for having mulitple terminals open on one screen - great for log-watching when developing.

You don't need X, all you need is a terminal.

MC does not take up the 1.4 Mb + shared libs + Gnome or N Mb + shared libs + KDE , which by the way only works if you have X also.

The 100% customizable build-in menu at the touch of a finger (F2) and of course file-extension feature works great - better than KDE or Gnomes version of the file-extension association lists... that don't work in all programs anyway.7

And it is almost as fast and versatile as the CLI. "Pure" CLI is still faster if you know the way around you keyboard...

And most of all no stupid mouse you have to reach out for when you want to view(F2)/edit(F3), copy(F5) or move(F6) a file (+ many more), the only thing you have to do is to reach an inch or a bit more depending on your keyboard and you got your action. When you do "system administration" work at the terminal then the mouse is not really an option.
If you don't believe me then give it a few weeks of testing. All there is to it, that goes for any and all GUI applications, is _not_ to use the mouse if there is a keyboard shortcut, including getting to menu items etc. It won't take you long to figure out that you loose time with the mouse, in just about any thing that is not drawing or moving windows around your desktop.
GUI = pretty pictures and tennis elbow, CLI = the fastest (also the choice that you need the most knowledge about GNU utilities to use), MC = CLI made easy and you get "free" visualisation of the filesystem.

If you aren't used to the CLI or the approx. 1000 "default" GNU utilities that comes with a default GNU/*nix installation that enables you to do just about anything you can thing of, excluding what your girlfriend can do, if you have one, then MC is the best way to get things done, fast and easy.

And of course, nostalgia from the "good" old DOS days where Norton Commander and DOS Navigator (some old MIT/russian NC clone that is much better than both NC and any NC clone I've run across, including MC).

I've got a Dell X1 weighing in on 1140 grams according to the specs... battery time is not something that is recommended but then I don't use it much outdoors anyways.

60 gig of (normal) hdd and 1280megs of ram for the small fee of about $3k almost 2 years ago... and it runs Gentoo and hasn't failed once... yet that is