I voted 2-3 years, because this is when I last assembled a PC. Then I have realized that the microcontrollers are also computers. I guess I have built 5 to 10 Atmel AVR-based boards for various DYI purposes during the last year.
Maybe this one will be next:
Why limit yourself to the X11 clients? I am perfectly happy with mutt (www.mutt.org). It is _fast_ (especially with local mail storage), does what I want it to do (I don't need calendar, for example), and can be used everywhere, including remote ssh session from my Android phone.
But it seems my requirements are different to what the OP needs.
A number of reviews mostly not all that recent have pointed to the main clients as Thunderbird, Evolution, Claws-mail, and Kmail as possibilities. Up to about a year ago Thunderbird seemed to be
"the" email client with the best mix of positives.
However there are no recent reviews that I have seen and in the meantime Thunderbird has moved to monthly releases which are more maintenance releases, with security fixes, with little real functional change — and little new development. Thunderbird won't be changed into the future much, if one interprets the available news information.
Evolution is reported to be rather prone to being buggy, and kmail even more so. Claws-mail has limitations as does kmail.
So where is the future going without any real innovation on available linux mail clients? We need a well maintained and capable mail
client, with preferably good calendar integration (webcal/google calendar), properly supported html composing, good maildir format storage for local mail, good security support including the capacity
to deal with both gpg and s/mime encryption and signing. It needs a good modern UI, and good import/export facilities as well as good
integration with its address book, including good import/export of addresses.
Are we likely to see this kind of package as we move into the future or will mail clients slowly disappear?
At the moment it looks like email client support is dead — maybe users are moving more into web mail and the cloud rather than having a properly functional mail client on their desktops?
I wonder what do people think?"
Also, unrelated, but I feel like the GNOME 3 hate is really blown out of proportion. Sure, some users were driven away, but the exact same thing happened with GNOME 2 and people called it trash and crap and whatever else.
And they were right.
I have been using GNOME since GNOME 1 times, and I think for former GNOME users the GNOME 3 fiasco is not something unexpected, it is a logical outcome of the overall trend in GNOME development.
I remember Sawmill/Sawfish being replaced by Metacity, which even in the latest GNOME 2 releases was not able to do things which were supported in Sawfish since day 1 and still are.
I remember Galeon being pushed out of GNOME and replaced by Epiphany (seriously, did anybody used Epiphany?), and again, Galeon was more capable than Firefox (and of course than Epiphany, but no surprise here), until it bit-rotted enough to be removed from Fedora about year and half ago.
I remember GDM being rewritten for GNOME 2.20, omitting XDMCP support altogether (a display manager without XDMCP, would you believe that?) and removing the config file, in which the user previously could set his own X server options, allowing, for example, correct multi-seat support. Those features were promised to be added later, but they never were, with the notable exception of the XDMCP support. And guess what? GDM in GNOME 3 is said to support multi-seat, but it generates its own hard-coded xorg.conf for secondary seats somewhere under
So no, GNOME 3 has not been a surprise, at least for me. GNOME 3 has been a logical outcome of the general trend, which has been visible in the GNOME development for several years. That said, GNOME 2 was bearable for me for general use (with Galeon, xdm, and Sawfish). When GNOME 3 was released, I have finally switched to XFCE.
Today all of our apps are network transparent.
Sadly, this is not true anymore. Many apps today depend on things like D-Bus or PulseAudio, which cannot be easily forwarded through the X protocol connection. Add a "run only a single instance of $app no matter what" mentality to the mix, and you are screwed: the $app started on a remote machine detects that another instance (on a completely different machine but the same display) is running, and tries to forward its own command line arguments to the previously running instance. But arguments like filenames are depended on the X client machine. Oops.
Link to Original Source
Link to Original Source
Link to Original Source