What really helps for this sort of use is a DMZ configuration. Laptops get put on dedicated network ports on a separate VLAN (if your switch doesn't support 'em, time to get one that does, or build parallel infrastructure), or even on a wireless network. Either way, all laptops go onto a network that arrives at a single dedicated port (physical or vlan'd virtual) on the firewall. The firewall treats that as untrusted as it would a DMZ, and only offers public external services to it.
If your laptop users want to get at internal network services, they use their IMAP+TLS, TLS-secured authenticated SMTP, etc - same as they do on the road. File access - WebDAV with SSL and client certificates.
If you must, then expose some "internal" services - but only the sort, such as TCP/IP database access ports, that won't be affected by most win32 worms.
If you isolate laptops from your network core even when they're on site, you'll be a lot better off. With half decent switches you can even configure things so that laptops *can't* be used on the "standard" ports by MAC-locking each port to its appropriate host. If a user knows enough to change the MAC address on their laptop to match their desktop, then change the plugs, you're probably beyond technical solutions (and into "fire them if they don't understand how to follow rules") anyway.
Honestly, it seems more like "IBM know how to get good PR".
There are still open questions about their manufacturing safety and pollution practises, they're lobbying hard for sofware patents in EU (as a developer and OSS contributor I have a BIG problem with that), etc.
On the scale, they don't seem to be doing that bad. Just don't forget that they're just doing whatever it currently takes to maximize profit and shareholder returns. Until/unless shareholder lawsuits against companies that try to do the "right thing" even if it impacts the bottom line become a thing of the past, that'll continue to be the way.
No more mockups that can't be translated into a real application front end.
That's old hat, at least in regular GUI development. If it's not to you, you need a better toolkit. I can't speak for web UI, however - I wouldn't be surprised if nothing that useful existed.
If they go down the standards path, I'll even be interested. I have a need to write some decent web UI soon, and really don't want to have to suffer the pain of DHTML and JavaScript.
What you really ideally want with the firewall is a switch that tags each machine for a separate vlan. The firewall gets traffic on all VLANs, each host only gets its own. No more worms spreading from an infected customer machine to a clean-but-unpatched one. Using VLANs should help let you network the PCs being tested without going completely insane, and without compromising client data.
Yes, that involves a switch that costs actual money. Not too much though - I bought a 24 port vlan capable managed switch with 10/100 with two gigabit ports for AU$650 (probably well sub-$500 US). If you only need a 16 or less, it's even cheaper.
The firewall of course would only forward traffic on specific ports, and only do HTTP/HTTPs through a non-transparent proxy (or perhaps even SOCKS).
I'd be inclined to put some sort of cheap Linux box on all the client VLANs too, so it can provide a read-only network file store for them.
Here's the The Adobe PDF reference, for if you want to implement applications that use PDF. In particular, you might want to read Section 1.5 of the PDF Reference, "Intellectual Property". In summary, it says that they'll enforce their copyright on the PDF specification in order to keep the standard accurate, but grant you the right to implement the standard pretty much however you like.
Some apps that do so, without licensing the Adobe PDf libraries or tools, include:
GhostScript OpenOffice.org Scribus Mac OS X (specifically the window system, print system, and Preview tool)... and *LOTS* more, including evince, xpdf, kpdf, libpoppler, and other open source PDF viewing tools/libs, several reporting libraries like ReportLab, etc.
The majority of the OO.o developers work for Sun. Others are with Red Hat, Novell, SuSE, etc. There's a fair bit of unpaid community involvement too as far as I know, but from what I've seen it's quite heavily business oriented.
So why are all these businesses putting in money for a free product? Because they all want to use it to drive sales of their money-making products. In Sun's case, that'll be for their thin client and desktop offerings (JDS, Sun Ray, etc).
There are certainly issues with this, but I don't think starving programmers will be one of those issues.
Lest you say I don't know what I'm talking about, while I'm not involved with the development of OO.o I/do/ work on Scribus (http://www.scribus.net/) in my spare time. I do this for learning, a challenge, and because its fun. I don't make my living off it, nor do I expect to, though I'm not adverse to making some money off it if the opportunity arises. Not everything is motivated purely by personal profit.
Build backwards compatibility into your contracts agreements with your vendors, and use the format that gives you the best technology.
That's essentially what MA have done. They set some requirements for document formats, evaluated the market offerings according to those criteria, and selected suitable current offerings for use. My understanding is that MS is *quite* welcome to support OpenDocument in order to re-enter the state suppliers list. Alternately, they should be able to adjust their new XML format license (or hand it off to a standards body) in order to qualify, too.
It looks to me like the state is saying "we require at least from our formats" and microsoft is saying "we don't want to give you that". It's much like a vendor refusing to sign a contract while it requires backward compatibility - it sends a warning signal sky high.
I think PDF support in Office is unlikely. While it'd be ideal - and since MS could license the Adobe PDF library, it'd be pretty quick for them - they're more likely to implement "Metro" support instead. That's the MS PDF-like format that they're talking about pushing with Vista.
Microsoft does not strike me as the sort of company that'd give Adobe free market exposure by shipping the Adobe Reader with the system, and licensing their PDF library. They could do as Apple have done and implement it themselves, but I think they'll want a format they control.
When it comes to OpenDocument, I suspect they're going to fight that for some time. Interoperability is a threat to the barrier to entry/exit around Office that lets them maintain inflated prices.
I'm in the useful position of being the BOFH and mail admin at work - at a fairly flexible and reasonable workplace - so I'm able to use my IMAP mailbox without fuss.
I can imagine that may not be true for some. However, POP3 won't help you - it's still gone through your company's mail filters, been logged, and if the company is really dodgy been scanned for "flag" words / analysed or even had a copy stored. The download protocol doesn't matter - either your company is not reading your mail, or they are.
The point is that if your company doesn't permit the use of work email for personal stuff, you're generally better off following that. Even if it's not reasonable - because they're not likely to be reasonable about it if there's a problem, either.
Decent IMAP clients support offline IMAP (they sync with the server when they can connect). This solves the one major downside of IMAP compared to POP3 for roaming users, and means that I simply see no need to even offer users the opportunity to shoot themselves in the foot with POP3.
It also means I don't have to talk users through recovering mailboxes from their home machines and sending them to me. Once I manage that, I have to restore them to some semblance of standards compliance by fixing whatever idiotic mangling their mail client has done (*cough*Eudora*cough*), and upload their local mail files back to the server where they belong. Ugh. Way better to just give the user the option of IMAP, IMAP, or IMAP.
I'm currently looking at how hard it'll be to make a customised Thunderbird installer for the user that comes bundled with a pre-configured IMAP account (with offline IMAP enabled) and has their client cert pre-installed. Preferably an install that they can simply copy off a CD and run - no setup process required. If only Thunderbird had some sort of writeable network address book support...
With POP3, the client downloads mail and deletes it off the server. Without a significantly butchered POP3 server there's no way to hold copies of that mail for a period of time (say, to ensure it goes on to your archival tapes, or to make sure you can recover files the user deleted accidentally). It's one less thing to worry about if their workstation / laptop dies, too - just give 'em another one. If more mail clients supported LDAP address books and WebDAV calendars this would be even nicer; as it is I still have to keep their mail folders in their network home dir so I can back up their address book.
You can back up POP3 boxes if you're on a corporate network, by forcing the client to keep its spools on the user's homedir. That tends to be slow and inefficient, though, and it doesn't let you do things like transparently split out attachments and store only one copy of an identical attachment for everybody.
It's also easy to lose mail with POP3 if your client does something silly. Most clients seem pretty decent now, but I remember old Eudora versions used to DELE mail off the server then crash, corrupting their mailboxes. Woohoo.
IMAP gives admins much more control over user mail. You can back up their mail folders, including their outbox and filed mail. You can enforce mail lifetime limits if your information retention policy requires it. You can store single copies of duplicate messages and attachments. You can give users access to shared mailboxes, and to each other's mailboxes where necessary. You can manage their mail folders remotely ("I can't delete $message, help!"). You can set up filters that deliver mail into sub-mailboxes automatically. Good clients automatically sync the IMAP mailbox so it can be used when the client is offline, like POP3. You can have your anti-spam software learn from their mail client's Junk folder. It's just much saner for business environments, in much the same way that network home directories and thin clients are much saner than a bunch of desktops with local storage are.
IMAP also permits you to give the user a single view of their mailboxes from their desktop and when they're on the road, or accessing their mail from home. Don't even talk about "leave mail on server" for POP3 - users WILL misconfigure it and suck all their mail down onto one of their machines, then come to you looking for help cleaning up the resulting awful mess.
Now, for an ISP, things are the opposite. You want to get the users' mail through your system and get rid of it. Most ISPs only offer POP3 and have small mailbox caps, so the user can't set their client to never delete mail off the server. They don't want to be responsible for user mail, they want it off their hands ASAP. An ISP can just tell a user who deleted a message then wants it back "well, that was silly then wasn't it?". An ISP doesn't want to back up 5 years worth of mail for 500,000 users.
My point is that for corporate environments IMAP is so superior that it's almost nuts to offer anything else, but for an ISP POP3 is a much more viable option. So what's so bad about POP3 depends entirely on what your needs are.
Yes, passwords are transmitted in plain text. So is IMAP, and so is SMTP. You do make your users authenticate for SMTP, right? Picking another protocol will not help in this regard.
What you need to do is support STARTTLS for these protocols. That lets the client connect then negotiate an encrypted connection with the server before sending passwords. It's easy to configure the server to refuse to authenticate the client unless an SSL session has been set up if that's what your security policy dictates. It's also possible to have the server demand a client certificate from the client before setting up the SSL connection, adding an extra layer of authentication.
You'll probably also have to support the old IMAPs, POP3s, and SMTPs standards, but they should be considered deprecated and only in place for crap clients that don't know about STARTTLS.
What POP3/IMAP server did you use? Personally, I've been using, and have been very happy with, Cyrus IMAPd.
Re IMAPs and POP3s, I agree that encrypted mail is crucual. You should offer SMTPs too. All the ssl-wrapped protocols are, however, somewhat obsolete. They're needed for older clients, where the client support exists the STARTTLS variants should be preferred. In particular, the SSL wrapped protocols are impractical for virtual domains because the server has to pick and send out a certificate before it has any way of knowing what hostname the client thinks it has.
You should also also offer standard IMAP, POP, and SMTP but enforce STARTTLS, so the server won't let the user authenticate without first negotiating SSL. The advantage here is primarily virtual domain support, but you can also cover more clients if you support both variants of each protocol (IMAPs and IMAP+TLS, etc).
If it's for corporate mail, I strongly suggest requiring the submission of a client certificate signed by your company's CA when connecting from the outside world. You can make your own CA and use it on your network without problems (just install the CA cert in the client by bundling it in the PKCS12 file with the user's client cert).
I couldn't agree more about the importance of mail filters like amavisd-new or MimeDefang to apply ClamAV and SpamAssassin checks. It's just too bad you'll need a stack of quad opterons with a apalling quantities of RAM to handle the load:S
The only large mail system I'm familar with uses Cyrus IMAPd's clustering facility, OpenLDAP, and postfix.
I'm particularly curious about the choice of Courier, and of NFS.
Courier I have little enough experience with to comment on. I was under the impression that it was a bit old and crufty, didn't have header caching for IMAP or other useful performance enhancements, and wasn't overly well suited to "sealed server" operation (rather than servers with direct user logins too). I would be interested to know why you passed up Cyrus IMAPd, as in my experience it's fantastic software that "just works" and I know there are sites that use it for gigantic volumes of mail.
I'm also interested in knowing what platform you're using given your use of NFS, though I guess maildir might be safe even on Linux NFS.
This article: www.linuxjournal.com/article/7323 may be helpful to you. It's not on quite the same scale, but it may be helpful. I know quite a few universities and companies run enormous Cyrus clusters with LDAP and a good UNIX MTA.
You might also want to ask on the info-cyrus mailing list.
GSSAPI, in case anyone here is unfamiliar with the term, is pretty much Kerberos 5. It's a key-based network authentication and security scheme used on many UNIX networks, and in a bastardised form by Windows AD domains.
It's also been on my "I really must implement that" list for waaaay too long. I find that more basic TLS-and-client-cert schemes do the job well enough most of the time.
That's punishing users with Lexmark printers, not Lexmark. I think this suggestion follows the same misguided logic as the recent wailing about MySQL building for SCO.
MySQL worked on SCO anyway. Note that SCO was quite free to package and ship it with the OS, for example.
To me, this seems like it's just making life a bit easier for the poor bastards stuck on the SCO platform. (I have to maintain a legacy SCO box, so I assure you I speak with full experience when I say "poor bastard").
I'm not super-fond of the idea but I just don't see what all the panic and fuss is about.
There's nothing wrong with gcc 3.3, it appears I was entirely mistaken there. Odd... I could've sworn it shipped with 2.95 . Perhaps I'm thinking of an older version.
"In an ideal world, it would be enforcible -- with exactly the same penalties as copyright infringement -- that every Derivative Work based upon a Work already in the Public Domain should be in the Public Domain. Under such circumstances, there would be no need for the GPL, since it would be all but enshrined in law."
I don't agree. Putting a work in the public domain gives anybody permission to do anything they wish with it. This seems appropriate enough. If you want a copyleft effect, you can simply license it as you desire.
Similarly, the BSD license is a viable choice. Sometimes you want your software to be available entirely freely, and are willing to have others do what they want with it. PostgreSQL is an interesting example of this.
I appreciate copyleft licenses, and contribute to projects that use them. I also think weak copyleft licenses (MPL, LGPL) have their place, as do the public domain and the BSD license.
Why should copyleft be imposed on people who are quite happy with a truly open license for their work?
Copyleft really isn't "almost as good". It's darn handy, and it often serves the purpose of the copyright owner and others well. However, for sheer freedom to do what you want with the work you can't beat the public domain - though the BSD license is very close.
Slashdot Mirror
What really helps for this sort of use is a DMZ configuration. Laptops get put on dedicated network ports on a separate VLAN (if your switch doesn't support 'em, time to get one that does, or build parallel infrastructure), or even on a wireless network. Either way, all laptops go onto a network that arrives at a single dedicated port (physical or vlan'd virtual) on the firewall. The firewall treats that as untrusted as it would a DMZ, and only offers public external services to it.
If your laptop users want to get at internal network services, they use their IMAP+TLS, TLS-secured authenticated SMTP, etc - same as they do on the road. File access - WebDAV with SSL and client certificates.
If you must, then expose some "internal" services - but only the sort, such as TCP/IP database access ports, that won't be affected by most win32 worms.
If you isolate laptops from your network core even when they're on site, you'll be a lot better off. With half decent switches you can even configure things so that laptops *can't* be used on the "standard" ports by MAC-locking each port to its appropriate host. If a user knows enough to change the MAC address on their laptop to match their desktop, then change the plugs, you're probably beyond technical solutions (and into "fire them if they don't understand how to follow rules") anyway.
Honestly, it seems more like "IBM know how to get good PR".
There are still open questions about their manufacturing safety and pollution practises, they're lobbying hard for sofware patents in EU (as a developer and OSS contributor I have a BIG problem with that), etc.
On the scale, they don't seem to be doing that bad. Just don't forget that they're just doing whatever it currently takes to maximize profit and shareholder returns. Until/unless shareholder lawsuits against companies that try to do the "right thing" even if it impacts the bottom line become a thing of the past, that'll continue to be the way.
No more mockups that can't be translated into a real application front end.
That's old hat, at least in regular GUI development. If it's not to you, you need a better toolkit. I can't speak for web UI, however - I wouldn't be surprised if nothing that useful existed.
If they go down the standards path, I'll even be interested. I have a need to write some decent web UI soon, and really don't want to have to suffer the pain of DHTML and JavaScript.
An absolute necessity is a POST card or two. Instead of highly vendor dependent beep codes, suddenly you have an LCD readout with useful information.
Now, if only standard PCs supported serial console access to BIOS, boot loader, *and* OS....
What you really ideally want with the firewall is a switch that tags each machine for a separate vlan. The firewall gets traffic on all VLANs, each host only gets its own. No more worms spreading from an infected customer machine to a clean-but-unpatched one. Using VLANs should help let you network the PCs being tested without going completely insane, and without compromising client data.
Yes, that involves a switch that costs actual money. Not too much though - I bought a 24 port vlan capable managed switch with 10/100 with two gigabit ports for AU$650 (probably well sub-$500 US). If you only need a 16 or less, it's even cheaper.
The firewall of course would only forward traffic on specific ports, and only do HTTP/HTTPs through a non-transparent proxy (or perhaps even SOCKS).
I'd be inclined to put some sort of cheap Linux box on all the client VLANs too, so it can provide a read-only network file store for them.
Here's the The Adobe PDF reference, for if you want to implement applications that use PDF. In particular, you might want to read Section 1.5 of the PDF Reference, "Intellectual Property". In summary, it says that they'll enforce their copyright on the PDF specification in order to keep the standard accurate, but grant you the right to implement the standard pretty much however you like.
... and *LOTS* more, including evince, xpdf, kpdf, libpoppler, and other open source PDF viewing tools/libs, several reporting libraries like ReportLab, etc.
Some apps that do so, without licensing the Adobe PDf libraries or tools, include:
GhostScript
OpenOffice.org
Scribus
Mac OS X
(specifically the window system, print system, and Preview tool)
The majority of the OO.o developers work for Sun. Others are with Red Hat, Novell, SuSE, etc. There's a fair bit of unpaid community involvement too as far as I know, but from what I've seen it's quite heavily business oriented.
/do/ work on Scribus (http://www.scribus.net/) in my spare time. I do this for learning, a challenge, and because its fun. I don't make my living off it, nor do I expect to, though I'm not adverse to making some money off it if the opportunity arises. Not everything is motivated purely by personal profit.
So why are all these businesses putting in money for a free product? Because they all want to use it to drive sales of their money-making products. In Sun's case, that'll be for their thin client and desktop offerings (JDS, Sun Ray, etc).
There are certainly issues with this, but I don't think starving programmers will be one of those issues.
Lest you say I don't know what I'm talking about, while I'm not involved with the development of OO.o I
That's essentially what MA have done. They set some requirements for document formats, evaluated the market offerings according to those criteria, and selected suitable current offerings for use. My understanding is that MS is *quite* welcome to support OpenDocument in order to re-enter the state suppliers list. Alternately, they should be able to adjust their new XML format license (or hand it off to a standards body) in order to qualify, too.
It looks to me like the state is saying "we require at least from our formats" and microsoft is saying "we don't want to give you that". It's much like a vendor refusing to sign a contract while it requires backward compatibility - it sends a warning signal sky high.
I think PDF support in Office is unlikely. While it'd be ideal - and since MS could license the Adobe PDF library, it'd be pretty quick for them - they're more likely to implement "Metro" support instead. That's the MS PDF-like format that they're talking about pushing with Vista.
Microsoft does not strike me as the sort of company that'd give Adobe free market exposure by shipping the Adobe Reader with the system, and licensing their PDF library. They could do as Apple have done and implement it themselves, but I think they'll want a format they control.
When it comes to OpenDocument, I suspect they're going to fight that for some time. Interoperability is a threat to the barrier to entry/exit around Office that lets them maintain inflated prices.
That seems justified.
I'm in the useful position of being the BOFH and mail admin at work - at a fairly flexible and reasonable workplace - so I'm able to use my IMAP mailbox without fuss.
I can imagine that may not be true for some. However, POP3 won't help you - it's still gone through your company's mail filters, been logged, and if the company is really dodgy been scanned for "flag" words / analysed or even had a copy stored. The download protocol doesn't matter - either your company is not reading your mail, or they are.
The point is that if your company doesn't permit the use of work email for personal stuff, you're generally better off following that. Even if it's not reasonable - because they're not likely to be reasonable about it if there's a problem, either.
Decent IMAP clients support offline IMAP (they sync with the server when they can connect). This solves the one major downside of IMAP compared to POP3 for roaming users, and means that I simply see no need to even offer users the opportunity to shoot themselves in the foot with POP3.
It also means I don't have to talk users through recovering mailboxes from their home machines and sending them to me. Once I manage that, I have to restore them to some semblance of standards compliance by fixing whatever idiotic mangling their mail client has done (*cough*Eudora*cough*), and upload their local mail files back to the server where they belong. Ugh. Way better to just give the user the option of IMAP, IMAP, or IMAP.
I'm currently looking at how hard it'll be to make a customised Thunderbird installer for the user that comes bundled with a pre-configured IMAP account (with offline IMAP enabled) and has their client cert pre-installed. Preferably an install that they can simply copy off a CD and run - no setup process required. If only Thunderbird had some sort of writeable network address book support...
Backups.
With POP3, the client downloads mail and deletes it off the server. Without a significantly butchered POP3 server there's no way to hold copies of that mail for a period of time (say, to ensure it goes on to your archival tapes, or to make sure you can recover files the user deleted accidentally). It's one less thing to worry about if their workstation / laptop dies, too - just give 'em another one. If more mail clients supported LDAP address books and WebDAV calendars this would be even nicer; as it is I still have to keep their mail folders in their network home dir so I can back up their address book.
You can back up POP3 boxes if you're on a corporate network, by forcing the client to keep its spools on the user's homedir. That tends to be slow and inefficient, though, and it doesn't let you do things like transparently split out attachments and store only one copy of an identical attachment for everybody.
It's also easy to lose mail with POP3 if your client does something silly. Most clients seem pretty decent now, but I remember old Eudora versions used to DELE mail off the server then crash, corrupting their mailboxes. Woohoo.
IMAP gives admins much more control over user mail. You can back up their mail folders, including their outbox and filed mail. You can enforce mail lifetime limits if your information retention policy requires it. You can store single copies of duplicate messages and attachments. You can give users access to shared mailboxes, and to each other's mailboxes where necessary. You can manage their mail folders remotely ("I can't delete $message, help!"). You can set up filters that deliver mail into sub-mailboxes automatically. Good clients automatically sync the IMAP mailbox so it can be used when the client is offline, like POP3. You can have your anti-spam software learn from their mail client's Junk folder. It's just much saner for business environments, in much the same way that network home directories and thin clients are much saner than a bunch of desktops with local storage are.
IMAP also permits you to give the user a single view of their mailboxes from their desktop and when they're on the road, or accessing their mail from home. Don't even talk about "leave mail on server" for POP3 - users WILL misconfigure it and suck all their mail down onto one of their machines, then come to you looking for help cleaning up the resulting awful mess.
Now, for an ISP, things are the opposite. You want to get the users' mail through your system and get rid of it. Most ISPs only offer POP3 and have small mailbox caps, so the user can't set their client to never delete mail off the server. They don't want to be responsible for user mail, they want it off their hands ASAP. An ISP can just tell a user who deleted a message then wants it back "well, that was silly then wasn't it?". An ISP doesn't want to back up 5 years worth of mail for 500,000 users.
My point is that for corporate environments IMAP is so superior that it's almost nuts to offer anything else, but for an ISP POP3 is a much more viable option. So what's so bad about POP3 depends entirely on what your needs are.
Yes, passwords are transmitted in plain text. So is IMAP, and so is SMTP. You do make your users authenticate for SMTP, right? Picking another protocol will not help in this regard.
What you need to do is support STARTTLS for these protocols. That lets the client connect then negotiate an encrypted connection with the server before sending passwords. It's easy to configure the server to refuse to authenticate the client unless an SSL session has been set up if that's what your security policy dictates. It's also possible to have the server demand a client certificate from the client before setting up the SSL connection, adding an extra layer of authentication.
You'll probably also have to support the old IMAPs, POP3s, and SMTPs standards, but they should be considered deprecated and only in place for crap clients that don't know about STARTTLS.
What POP3/IMAP server did you use? Personally, I've been using, and have been very happy with, Cyrus IMAPd.
:S
Re IMAPs and POP3s, I agree that encrypted mail is crucual. You should offer SMTPs too. All the ssl-wrapped protocols are, however, somewhat obsolete. They're needed for older clients, where the client support exists the STARTTLS variants should be preferred. In particular, the SSL wrapped protocols are impractical for virtual domains because the server has to pick and send out a certificate before it has any way of knowing what hostname the client thinks it has.
You should also also offer standard IMAP, POP, and SMTP but enforce STARTTLS, so the server won't let the user authenticate without first negotiating SSL. The advantage here is primarily virtual domain support, but you can also cover more clients if you support both variants of each protocol (IMAPs and IMAP+TLS, etc).
If it's for corporate mail, I strongly suggest requiring the submission of a client certificate signed by your company's CA when connecting from the outside world. You can make your own CA and use it on your network without problems (just install the CA cert in the client by bundling it in the PKCS12 file with the user's client cert).
I couldn't agree more about the importance of mail filters like amavisd-new or MimeDefang to apply ClamAV and SpamAssassin checks. It's just too bad you'll need a stack of quad opterons with a apalling quantities of RAM to handle the load
I find your design interesting.
The only large mail system I'm familar with uses Cyrus IMAPd's clustering facility, OpenLDAP, and postfix.
I'm particularly curious about the choice of Courier, and of NFS.
Courier I have little enough experience with to comment on. I was under the impression that it was a bit old and crufty, didn't have header caching for IMAP or other useful performance enhancements, and wasn't overly well suited to "sealed server" operation (rather than servers with direct user logins too). I would be interested to know why you passed up Cyrus IMAPd, as in my experience it's fantastic software that "just works" and I know there are sites that use it for gigantic volumes of mail.
I'm also interested in knowing what platform you're using given your use of NFS, though I guess maildir might be safe even on Linux NFS.
This article:
www.linuxjournal.com/article/7323
may be helpful to you. It's not on quite the same scale, but it may be helpful. I know quite a few universities and companies run enormous Cyrus clusters with LDAP and a good UNIX MTA.
You might also want to ask on the info-cyrus mailing list.
GSSAPI, in case anyone here is unfamiliar with the term, is pretty much Kerberos 5. It's a key-based network authentication and security scheme used on many UNIX networks, and in a bastardised form by Windows AD domains.
It's also been on my "I really must implement that" list for waaaay too long. I find that more basic TLS-and-client-cert schemes do the job well enough most of the time.
That's punishing users with Lexmark printers, not Lexmark. I think this suggestion follows the same misguided logic as the recent wailing about MySQL building for SCO.
SCO != SCO customers
MySQL worked on SCO anyway. Note that SCO was quite free to package and ship it with the OS, for example.
To me, this seems like it's just making life a bit easier for the poor bastards stuck on the SCO platform. (I have to maintain a legacy SCO box, so I assure you I speak with full experience when I say "poor bastard").
I'm not super-fond of the idea but I just don't see what all the panic and fuss is about.
There's nothing wrong with gcc 3.3, it appears I was entirely mistaken there. Odd... I could've sworn it shipped with 2.95 . Perhaps I'm thinking of an older version.
"In an ideal world, it would be enforcible -- with exactly the same penalties as copyright infringement -- that every Derivative Work based upon a Work already in the Public Domain should be in the Public Domain. Under such circumstances, there would be no need for the GPL, since it would be all but enshrined in law."
I don't agree. Putting a work in the public domain gives anybody permission to do anything they wish with it. This seems appropriate enough. If you want a copyleft effect, you can simply license it as you desire.
Similarly, the BSD license is a viable choice. Sometimes you want your software to be available entirely freely, and are willing to have others do what they want with it. PostgreSQL is an interesting example of this.
I appreciate copyleft licenses, and contribute to projects that use them. I also think weak copyleft licenses (MPL, LGPL) have their place, as do the public domain and the BSD license.
Why should copyleft be imposed on people who are quite happy with a truly open license for their work?
mmap() is pretty high up the list, too. It's *so* annoying not being able to mmap files where appropriate, because win32 doesn't understand it.
In particular, SFU is severely and notably lacking:
* an X server
* SSH
* libraries and a compiler this side of the stone age
Copyleft really isn't "almost as good". It's darn handy, and it often serves the purpose of the copyright owner and others well. However, for sheer freedom to do what you want with the work you can't beat the public domain - though the BSD license is very close.
I didn't, for example, and I've been using Linux (RH and Debian) since RH 6.2 .
That said, I've never run into the issue.
From the description given, it seems that this is mostly a user interface issue. A helpful message might well be all it takes.