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
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
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?
What will become of MySQL and Java ?"
Link to Original Source
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 email@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 firstname.lastname@example.org.
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 email@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 firstname.lastname@example.org.
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
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).
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