Using the alternative SMTP submission port, 587, as detailed in RFC 2476, is what is needed for users that have port 25 blocked by their ISP so that SPF works simply for their domain. Email client support for alternative ports was not common when the RFC was written in 1998, but every client has support for it today, so there is no excuse. The great advantage of configuring your laptop to always use port 587, is that you can plug the laptop in anywhere on the Internet and your email just works.
I filed a bug about this with sourceforge years ago. I just wasn't big enough to get them to fix it.
The bug has do to the MAIL FROM and RCPT TO protocol. If you use MAIL FROM: , then the RCPT TO: address is supposed to be a bounce address, ie., one that you received. My setup signs all of its MAIL FROM addresses (with SRS), so I can detect bogus bounces. Likewise, if you use a normal, non-bounce RCPT TO address then the MAIL FROM address must be a real address on the sending site (so it passes SPF checks). Pretty simple for sourceforge to fix. Since I'm a small fry, I had to fix it on my end by delaying the verification until the DATA command was received -- not hard, but not as simple.
MAIL FROM address verification is a good technique to only accept email you can probably bounce to if there is an error, but it's not needed if the sending site support SPF (if a bounce fails, just blacklist the sending site because it's giving out bogus information).
Even though it wouldn't work today, I'd recommend publishing the IP addresses that are allowed to send email for your domain with a SPF record see http://spf.pobox.com.
That will give email receivers enough information to override the blacklisting and effectively whitelist your domain.
I don't use MAPS, but do blacklist residental Internet connections, so when people in your situation send me email (as the postmaster for a domain diluged with spam), I offer to whitelist them until I get SPF-based whitelisting implemented. If I am the first to add that technology to sendmail, you'll see a post on sendmail newsgroup.
The display isn't the problem on the Mac, it's the lack of stereo-capable OpenGL drivers.
That said, for molecular modeling, a $2500 PC (say $1500 for the PC and $1000 for the workstation class graphics card) runs circles around a $12000+ SGI workstation. The graphics drivers support the latest variations of OpenGL and the quality of implementation of the graphics drivers is finally catching up to SGI's.
I love our SGI Octane2 V12, but I can't recommend it.
We still consider the OSX version of chimera to be a beta version primarily because the Aqua version of the Tcl/Tk toolkit (that chimera uses) still needs work. Consequently, we are currently supplying a OSX X11 version that runs well under the Apple X server.
Chimera uses OpenGL, so yes it exploits the graphics accelerators. Apple is using chimera to help debug its graphics drivers, so the performance should only improve.
Quad-buffered stereo is double-buffered for both the left and the right eye images so they always remain in sync. While any stereo technique has to quad-buffer, if the OpenGL driver exposes its quad-buffering API, then the native windowing system has to support stereo in a window.
The VRex is interesting because it makes odd scan lines go to one eye and even to the other. So even though you loose half your vertical resolution for stereo images, mono images (the GUI) are unaltered.
As for for PyMol versus chimera, you'll have to do the comparison yourself. We both have our strengths and weaknesses and both are constantly improving.
Having written stereo code for a molecular graphics program, UCSF chimera, I really want quad-buffered stereo in a window so my program can present a modern GUI and a stereo image at the same time. I don't like blue-line stereo because it is for full screen stereo and that screws up the GUI. Unfortunately for the Mac, I know of no graphics cards that support quad-buffered stereo. We have asked Apple about it and they are "considering" it. Please keep pressuring Apple to add quad-buffered stereo support -- it will only happen if Apple does it because Apple writes its own graphics card drivers. In the mean time, check out the micropol displays from Vrex. We have preliminary support for them in chimera and I'm sure you could get Warren Delano to add support to pymol.
The Exploratorium. Especially, the activities in the "Accidental Scientist" and "Try This!" sections. And if you're ever in San Francisco, you should visit it. Lots of hands on exhibits designed for kids. Can't say enough good things about it.
I would love to see that press release. It doesn't appear to be on the Apple website yet.
I'm really curious how Apple is going to price stereo support. Currently, NVidia and ATI make you buy the workstation version of their video cards, a $800 to $1500 card, instead of a $200 to $400 consumer card, if you want a stereo connector with driver support. If Apple sells stereo at a small premimum, then that reduces the market for the high-margin workstation cards. Not clear if NVidia or ATI will let them or continue to sell to Apple.
Another interesting aspect to this is that Apple writes its own drivers for NVidia and ATI chips and right now Apple has the buggiest OpenGL drivers out there (i.e., my molecular graphics application can crash Mac OS X doing legal OpenGL, -- works fine on Linux and Windows with similar chips, and on SGIs). There are tricky aspects to adding stereo support to the drivers if you want the stereo drawing to be in a window with the GUI drawn normally (with Aqua in mono). I hope the Apple driver team is up to the task!
Have you looked at creating a picogui X extension? That would provide a clean way of using picogui with X servers and provide a clean migration path to picogui for X application writers.
Slashdot Mirror
Using the alternative SMTP submission port, 587, as detailed in RFC 2476, is what is needed for users that have port 25 blocked by their ISP so that SPF works simply for their domain. Email client support for alternative ports was not common when the RFC was written in 1998, but every client has support for it today, so there is no excuse. The great advantage of configuring your laptop to always use port 587, is that you can plug the laptop in anywhere on the Internet and your email just works.
I filed a bug about this with sourceforge years ago. I just wasn't big enough to get them to fix it. The bug has do to the MAIL FROM and RCPT TO protocol. If you use MAIL FROM: , then the RCPT TO: address is supposed to be a bounce address, ie., one that you received. My setup signs all of its MAIL FROM addresses (with SRS), so I can detect bogus bounces. Likewise, if you use a normal, non-bounce RCPT TO address then the MAIL FROM address must be a real address on the sending site (so it passes SPF checks). Pretty simple for sourceforge to fix. Since I'm a small fry, I had to fix it on my end by delaying the verification until the DATA command was received -- not hard, but not as simple. MAIL FROM address verification is a good technique to only accept email you can probably bounce to if there is an error, but it's not needed if the sending site support SPF (if a bounce fails, just blacklist the sending site because it's giving out bogus information).
I don't use MAPS, but do blacklist residental Internet connections, so when people in your situation send me email (as the postmaster for a domain diluged with spam), I offer to whitelist them until I get SPF-based whitelisting implemented. If I am the first to add that technology to sendmail, you'll see a post on sendmail newsgroup.
That said, for molecular modeling, a $2500 PC (say $1500 for the PC and $1000 for the workstation class graphics card) runs circles around a $12000+ SGI workstation. The graphics drivers support the latest variations of OpenGL and the quality of implementation of the graphics drivers is finally catching up to SGI's.
I love our SGI Octane2 V12, but I can't recommend it.
Chimera uses OpenGL, so yes it exploits the graphics accelerators. Apple is using chimera to help debug its graphics drivers, so the performance should only improve.
Quad-buffered stereo is double-buffered for both the left and the right eye images so they always remain in sync. While any stereo technique has to quad-buffer, if the OpenGL driver exposes its quad-buffering API, then the native windowing system has to support stereo in a window.
The VRex is interesting because it makes odd scan lines go to one eye and even to the other. So even though you loose half your vertical resolution for stereo images, mono images (the GUI) are unaltered.
As for for PyMol versus chimera, you'll have to do the comparison yourself. We both have our strengths and weaknesses and both are constantly improving.
Having written stereo code for a molecular graphics program, UCSF chimera, I really want quad-buffered stereo in a window so my program can present a modern GUI and a stereo image at the same time. I don't like blue-line stereo because it is for full screen stereo and that screws up the GUI. Unfortunately for the Mac, I know of no graphics cards that support quad-buffered stereo. We have asked Apple about it and they are "considering" it. Please keep pressuring Apple to add quad-buffered stereo support -- it will only happen if Apple does it because Apple writes its own graphics card drivers. In the mean time, check out the micropol displays from Vrex. We have preliminary support for them in chimera and I'm sure you could get Warren Delano to add support to pymol.
The Exploratorium. Especially, the activities in the "Accidental Scientist" and "Try This!" sections. And if you're ever in San Francisco, you should visit it. Lots of hands on exhibits designed for kids. Can't say enough good things about it.
Yes we have filed the bug. It is taking longer than I expected to fix iy, but maybe I have unrealistic expectations.
I'm really curious how Apple is going to price stereo support. Currently, NVidia and ATI make you buy the workstation version of their video cards, a $800 to $1500 card, instead of a $200 to $400 consumer card, if you want a stereo connector with driver support. If Apple sells stereo at a small premimum, then that reduces the market for the high-margin workstation cards. Not clear if NVidia or ATI will let them or continue to sell to Apple.
Another interesting aspect to this is that Apple writes its own drivers for NVidia and ATI chips and right now Apple has the buggiest OpenGL drivers out there (i.e., my molecular graphics application can crash Mac OS X doing legal OpenGL, -- works fine on Linux and Windows with similar chips, and on SGIs). There are tricky aspects to adding stereo support to the drivers if you want the stereo drawing to be in a window with the GUI drawn normally (with Aqua in mono). I hope the Apple driver team is up to the task!
Have you looked at creating a picogui X extension? That would provide a clean way of using picogui with X servers and provide a clean migration path to picogui for X application writers.