That reminds me. It's time to pick up the ad-free version of Opera and a few more games from Loki.
I encourage the rest of you to give in to the American consumerist way. Drown your sorrow at this linux product folding with credit card receipts from companies that still support linux.
Or, more succinctly, put your money where your mouth is.
The original post said: The only involvement the university had was hosting the site and buying the server, that's it.
So you're saying, in essense, "They paid for the server, the building it was located in, and the network infrastructure that it used", but that's it.
That, unfortunately for you, is quite enough. Unless you had explicit written permission to do what you did, your legal standing is the same as that of an artist who painted a picture on the side of somebody else's building. You have no right to complain when they wash the building and wipe away your "speech".
The lesson: get permission for everything in advance and in writing.
That's not how most caches work. The first user to hit a site makes the cache pull the data from the remote site, but then the cache saves the data. So, the cache doesn't grab any more than it needs. --
Try putting more than a dozen 802.11b access points within earshot of each other.
I wish "too many access points" was a problem that I had to deal with. Every wireless install plan that I've seen has assumed some degree of airspace cooperation, and the emphasis is usually on covering an area with as few access points as possible.
You make a good point about dropping connections with 802.11b, but unless things have changed in the last few months, all of the 802.11a stuff that I've seen has the same problem.
how come nobody talks about the 26mb FHSS equipment that is due to come out soon.
There's a lot of cool technology that's "due to come out soon." When it makes the transition from vaporware to hardware, we'll talk about it. I suspect that it'll have the same problems as most high-speed wireless "extensions": you only get the speed if you're within a few feet of the access point. Otherwise, it drops back to the same old slow speed.
802.11a becomes saturated much more quickly. Try putting more than a dozen users on an 802.11a access point. IF it works, it'll be amazingly slow.
I haven't read both specs, but I'd guess that 802.11b (Wi-Fi) devices can share a frequency, while 802.11a devices just hop to a new freqency if theirs is in use. When the number of users gets close to the number of frequencies, things fall over and go boom.
I work for a university that recently deployed a large wireless network, and 802.11a was totally unacceptable for even a medium-sized classroom. 802.11b was able to handle the load, though it is pretty slow when you have 50 users sharing a 2Mbps connection.
NetBSD 1.5 (the latest release) uses an unusual init setup that captures many of the good things about SysV style init while removing some of the stupid things. Each script can have a prereqisite script. So, sendmail might have networking as it's prerequisite. You get the cleanliness of separate scripts without the stupid number juggling of sysv.
Personally, I'd like to see a distro with a linux kernel but BSD userland, ports, etc.
That means I can take advantage
of best speed everywhere else, and use table-level locking on this one transaction just to be safe. These are not options
in most large RDBMS', but certainly are in something like MySQL.
You've never used a large RDBMS, have you?
Most RDBMS' do allow you to choose between speed and ACID/atomicity/etc. DB2 supports a boggling array of options, including a MySQL-style "store with no security whatsoever" option. The latest SQL spec even provides standard terminology for some of these features. Most of the big DBs provide more speed vs. reliability reatures than the spec requires.
There is at least one military organization that decomissions drives by overwriting them a bunch of times. Then, they cut the drive in half with a saw and take each half to a different facility for disposal (which usually involves melting the drive).
I work in Computing Services for a tech-oriented private university. Our usage policies aren't as bad as some, but they definitely give us broad priviledges. We've been through many, many proposed revisions that keep being killed by some combination of faculty, staff or lawyers. The basic problems:
There doesn't seem to be a concise legal way to say "Don't be an asshole and don't break the law," which is all we really want.
It's occasionally necessary for staff to look at private information for technical reasons (reconstructing mail spool after disk crashed, making sure the nifty new backup program actually worked, etc.). We have a huge infrastructure, and if we had to stop and check every time we might accidentally see something, we'd never get anything done unless we made our staff size much larger. We don't have the budget to do that.
Occasionally, the sysadmins will find something really bad during the course of routine work. "Spending a long time in federal prison" kind of bad. We try to keep these sort of events quiet to avoid publicity for the user in case it's not their fault (someone cracked their account, etc). We don't want our users on the evening news, but this'll happen with most "notify lots of people before doing anything" plans.
There are two opposing viewpoints that are both vocal in our community. One says "privacy over all" while the other says "learning and sharing over all". We have quite a few people who make their home directories publicly readable as a sort of protest against the "privacy freaks" (their words). Finding a policy that makes both happy is very difficult.
In light of these constraints (financial and social), how do we give more rights to our users without seriously impeding our ability to do our jobs?
Hmm.. well most people will tell that at least four detailed first-person accounts of Jesus existing are around.. one authored directly by Luke, and three more dictated by Matthew, Mark, and John.
Unfortunately, none of these people would be biblical scholars. There are some people who try very, very hard to correlate the bible with historical fact. Very few of these people believe that those books were, in fact, written by Matthew, Mark, Luke, and John. Those books were considered "good sources" at the time that the bible was assembled -- several hundred years after the death of Jesus -- and their authorship was attributed to those Apostles to give them greater legitimacy.
I don't know that I'd call Macs expensive and slow (considering what you get), but I sort of agree with you.
You see, I've watched the BSDs since before I first installed Slackware from a big pile of floppy disks years ago. I -wanted- to use the BSDs, but I couldn't. At the time, I had a proprietary CD-ROM drive that's still not supported by anything but linux, and I was using IDE, which the BSDs didn't yet support. I used that machine until I got my 486 with a parallel-port zip drive that linux supported, but the BSDs didn't. Now, I'm running a dual-processor machine that only linux can use effectively.
Linux's real market is in getting more use out of existing hardware. With OSX, you're buying hardware to support the OS. With Linux, you're getting an OS for free that runs on whatever hardware you already have. I can buy a new Super-GX-Pro-64-Turbo-Mega graphics card, and if it's not supported yet, it will be next month. I can also pull my old 386sx out of the closet, and it'll be supported too. Nobody but Linux can do that.
It's actually pretty simple: make the handbook say pretty much what you're saying here. You want to preserve your rights, while providing some assurance that you won't routinely spy on your employees "just in case". Perhaps something like this:
The company reserves the right to monitor or search all company property and equipment if improper or illegal conduct is suspected. However, all such monitoring or searching will be performed with at least one witness or explicit written instruction from at least two managers.
I'm not a lawyer. Run the above past one before using it.
HR46 <strong>did</strong> go through without the amendment. Hatch added the amendment in the senate, so it has to go back through the house. It has not done so yet, and will not do so before January.
I called my congressman (William Coyne) as soon as I saw this on Slashdot, and I just got a call back from someone on his staff. According to him, HR 46 hasn't come up for a vote yet, and as congress adjourned last week, it's unlikely to come up before January.
The staffer that I talked to was a very nice fellow, and he did say that it's possible that it might have been slipped into one of the big omnibus appropriations bills, but HR 46 did not go through on its own.
Theo Said: In Linux land, it appears that projects fork for financial reasons. In
BSD land, it appears that the forks that have happened were purely
political reasons. I don't know what will happen. It's been 5 years
since the last fork in the BSD camp. Why are you guys so fork
paranoid?
I suspect that the question was rhetorical, but it deserves an answer. I'm putting it here, with the other fork comment, even though it wasn't written as a follow-up to that comment.
Simply put, it's (too) often used as an object lesson in Linux land.
Whenever an argument gets too heated, someone jumps in with "if we
keep acting like this, we'll end up like the BSDs." Meaning, I
suppose, "fighting over a very tiny percentage of mindshare instead of
working together to take over the world."
I suspect that Linux is headed toward a fork. Linus and Alan Cox have
been leaving things out of the kernel (like a debugger) that a lot of
people want. As there's no charter or formal organizational structure, I
think that a coup of some sort is inevitable. When it happens, the
interest in the Net/Open split will rise to a crescendo.
I have friends who are OpenBSD advocates, and others who are NetBSD
advocates. To hear each side talk, the other side writes crappy code
between bouts of trying to ruin BSD for everybody. It's depressing,
particularly when I think about what could happen if their talents
could be combined. Or, if they would just shut up, stop sniping at
each other, and code.
I'd love to see some sort of cross-bsd advocacy organization to help
users take that middle step. Help with porting of cool shit between
the BSDs. Make generic cross-BSD documentation. Help people decide
which OS and user/developer community is right for them. etc.
Unfortunately, that requires a friendlier attitude than I often see
between the BSDs. Charges of "code theft" particularly frustrate me.
That's the whole damned point of open source: Seeing the good stuff,
learning from it, and using it.
Almighty Nielsen would disagree with you where screen fonts are concerned
Then he disagrees with almost every other typesetting usability study and style guide in existance. Perhaps his studies are based on sales sites (where there are lots of proper names) or it's an issue with the low resolution of computer monitors (where the serifs are "extra junk" rather than visual cues).
I think that the enemy of the good for onscreen body font selection is the unconventional.
After reading this a few times, I agree with you. For me, "conventional" is the user's default browser font(s).
Text should be in a table with a width of approx 200 - 500 pxls.
Let people decide this with their browsers, and never specify sizes in pixels. It looks awful on small monitors (say, PDAs, or Grandma's 640x480 monitor), and it's awful AND hard to read on a 1600x1200 display.
Do NOT put large amounts of text into a single, monolithic table. This may cause a user's browser to have to wait for the whole page to be loaded until they see any text.
This is a government web site, not a sales site. The goal is complete and accurate information, not loading speed. You need to realize that there are some people who HAVE to use special browsers (blind, etc.), and there are others who just don't want to use IE or Netscape, and these users would rather have all of their information in a single block rather than having their browser say "left-brace table right-brace left-brace tee arr right-brace left-brace tee dee right-brace" etc. before and after each paragraph.
Use sans-serif fonts
No. Let the user choose his own fonts in his browser. You're wrong about serifs and readability. Sans-serif is easier to read when the words are unfamiliar (proper nouns, technical jargon, etc.). Serifed fonts are easier to read for normal text, so long as the reader understands the words that are being used.
Give links for a zip-file of all text
There are many people, particularly in this august forum, who do not use windows. For these people, zip files are an inconvenience. Providing plain text files is a good idea, though.
I was inferring from the text what you say he never said. It is literally true that he did not say them, but it is nevertheless possible to infer that he meant them.
I've yet to find any claims that weren't obviouly biased (Open people saying that Open is better, Free people saying that Free is better, etc.). I think of myself as a Linux guy, but I like to play with all of the BSDs.
My own perceptions:
FreeBSD is nifty, and accepts code almost as liberally as Linux. That is, poorly written but functional is acceptable. This tends to result in FreeBSD having more nifty features that work before any of the other BSDs. However, the design is very evolutionary and distributed, and some bits of the code are just plain scary. Broken things that lots of people care about (like speed issues) are fixed quickly. Broken things that not many people care about tend to be ignored.
NetBSD contains the sort of code that'd make CS professors proud. It's clean and well-documented, and there's a lot of thought given to design and the larger picture. Like a CS project, though, it tends to be slow, as the most intuitive way to do things is often not the fastest. There are also times when the "run on anything" focus gets in the way of maximum performance.
OpenBSD audits their code for security, and the auditing gets rid of the worst of the poorly written code, but sometimes, the most secure design is horrifically unintuitive. The newer bits (like OpenSSH) show this the most: you'll need to make a sanity check after looking at some bits of that code. I really REALLY like the emphasis on security, though. It feels a little bit slower than FreeBSD, but not as slow as NetBSD. I have no hard numbers to back me up, just personal perception.
A lot of people know that OpenBSD forked from NetBSD, and there's still some animosity between the two groups. Personally, I think that the competition has helped both groups (NetBSD now ships with far fewer open services, for example).
Egos are delicate things, but do you see any chance for greater cooperation in the future, or do you see more forking and division as inevitable?
Exchange has two "advantages" over it's competitors: it's easy to set up (compared to Solaris, sendmail, imap), and it presents a uniform interface for users.
The first isn't an issue for you since you already have Solaris et al. set up.
As for the second, there's no particular functionality that Exchange/Outlook provides that isn't handled by other, separate programs. That's just a matter of user education. You can run Netscape/CS&T's calendar server on the Solaris machine, if it's calendaring you want. There are some weird hooks into Outlook from some other MS products (DevStudio, for example) that can be replicated pretty easily with CVS and a shell script.
You're probably aware of the disadvantages. HA isn't an option: it WILL crash. You'll need a dedicated NT sysadmin if you don't already have one. Preferrably one who's had to rebuild an Exchange server after it's crashed (which can be a brutal, time consuming job) and not a fresh "I just got my MCSE so I must be smart" type. Expect to have planned outages weekly to reboot "just in case", because otherwise the monthly crashes will be unscheduled and will take significantly loger to recover from. The exchange box should be a really really beefy single CPU machine with as much memory and disk as can be managed (as in, it'll cost as much as a Sun), and nothing except Exchange should run on it, to reduce the frequency of crashes.
If we implement electronic ballots, we'll need two completely separate systems. One for authentication, and another for voting, with no communication between the two.
One of the critical concepts in the american voting system is anonymity. The current system, for all its flaws, achieves this. They know that I voted, but they don't know who I voted for. This was done because people in power (at any level: bosses, politicians, even husbands) were able to force people to vote one way or another by retaliating if someone voted "incorrectly."
A lot of the "vote on the internet" stuff that you see doesn't have this anonymity. Electronic booths to replace the levers and punchcards are a good idea. Voting booths that might permit traceable votes aren't. If we're worried about people making it to the polls, we need to look at the absentee ballot handling (Oregon has a fantastic system for this) and perhaps we should declare voting day a national holiday and strongly discourage businesses from remaining open. --
Slashdot Mirror
I encourage the rest of you to give in to the American consumerist way. Drown your sorrow at this linux product folding with credit card receipts from companies that still support linux.
Or, more succinctly, put your money where your mouth is.
--
This page contains 2 cookies from ads.example.com.
(_) This cookie only
(_) All cookies from this domain
(_) All cookies
[Accept] [Reject] [Cancel]
This way, I can choose once per site whether to allow cookies. Slashdot gets cookies. Sites where I'm not registered don't.
--
The only involvement the university had was hosting the site and buying the server, that's it.
So you're saying, in essense, "They paid for the server, the building it was located in, and the network infrastructure that it used", but that's it.
That, unfortunately for you, is quite enough. Unless you had explicit written permission to do what you did, your legal standing is the same as that of an artist who painted a picture on the side of somebody else's building. You have no right to complain when they wash the building and wipe away your "speech".
The lesson: get permission for everything in advance and in writing.
--
That's not how most caches work. The first user to hit a site makes the cache pull the data from the remote site, but then the cache saves the data. So, the cache doesn't grab any more than it needs.
--
Does anyone sell systems based on the Sandpoint design? While an open platform is really cool, I don't want to assemble one myself.
Presumably, someone has produced a production board that's closely related to this reference design.
--
I wish "too many access points" was a problem that I had to deal with. Every wireless install plan that I've seen has assumed some degree of airspace cooperation, and the emphasis is usually on covering an area with as few access points as possible.
You make a good point about dropping connections with 802.11b, but unless things have changed in the last few months, all of the 802.11a stuff that I've seen has the same problem.
how come nobody talks about the 26mb FHSS equipment that is due to come out soon.
There's a lot of cool technology that's "due to come out soon." When it makes the transition from vaporware to hardware, we'll talk about it. I suspect that it'll have the same problems as most high-speed wireless "extensions": you only get the speed if you're within a few feet of the access point. Otherwise, it drops back to the same old slow speed.
--
I haven't read both specs, but I'd guess that 802.11b (Wi-Fi) devices can share a frequency, while 802.11a devices just hop to a new freqency if theirs is in use. When the number of users gets close to the number of frequencies, things fall over and go boom.
I work for a university that recently deployed a large wireless network, and 802.11a was totally unacceptable for even a medium-sized classroom. 802.11b was able to handle the load, though it is pretty slow when you have 50 users sharing a 2Mbps connection.
--
NetBSD 1.5 (the latest release) uses an unusual init setup that captures many of the good things about SysV style init while removing some of the stupid things. Each script can have a prereqisite script. So, sendmail might have networking as it's prerequisite. You get the cleanliness of separate scripts without the stupid number juggling of sysv.
Personally, I'd like to see a distro with a linux kernel but BSD userland, ports, etc.
--
You've never used a large RDBMS, have you?
Most RDBMS' do allow you to choose between speed and ACID/atomicity/etc. DB2 supports a boggling array of options, including a MySQL-style "store with no security whatsoever" option. The latest SQL spec even provides standard terminology for some of these features. Most of the big DBs provide more speed vs. reliability reatures than the spec requires.
--
See Peter Gutmann's Usenix paper on secure deletion of data from magnetic and solid state memory for some truly impressive data recovery methods.
--
I work in Computing Services for a tech-oriented private university. Our usage policies aren't as bad as some, but they definitely give us broad priviledges. We've been through many, many proposed revisions that keep being killed by some combination of faculty, staff or lawyers. The basic problems:
- There doesn't seem to be a concise legal way to say "Don't be an asshole and don't break the law," which is all we really want.
- It's occasionally necessary for staff to look at private information for technical reasons (reconstructing mail spool after disk crashed, making sure the nifty new backup program actually worked, etc.). We have a huge infrastructure, and if we had to stop and check every time we might accidentally see something, we'd never get anything done unless we made our staff size much larger. We don't have the budget to do that.
- Occasionally, the sysadmins will find something really bad during the course of routine work. "Spending a long time in federal prison" kind of bad. We try to keep these sort of events quiet to avoid publicity for the user in case it's not their fault (someone cracked their account, etc). We don't want our users on the evening news, but this'll happen with most "notify lots of people before doing anything" plans.
- There are two opposing viewpoints that are both vocal in our community. One says "privacy over all" while the other says "learning and sharing over all". We have quite a few people who make their home directories publicly readable as a sort of protest against the "privacy freaks" (their words). Finding a policy that makes both happy is very difficult.
In light of these constraints (financial and social), how do we give more rights to our users without seriously impeding our ability to do our jobs?--
Unfortunately, none of these people would be biblical scholars. There are some people who try very, very hard to correlate the bible with historical fact. Very few of these people believe that those books were, in fact, written by Matthew, Mark, Luke, and John. Those books were considered "good sources" at the time that the bible was assembled -- several hundred years after the death of Jesus -- and their authorship was attributed to those Apostles to give them greater legitimacy.
--
I don't know that I'd call Macs expensive and slow (considering what you get), but I sort of agree with you.
You see, I've watched the BSDs since before I first installed Slackware from a big pile of floppy disks years ago. I -wanted- to use the BSDs, but I couldn't. At the time, I had a proprietary CD-ROM drive that's still not supported by anything but linux, and I was using IDE, which the BSDs didn't yet support. I used that machine until I got my 486 with a parallel-port zip drive that linux supported, but the BSDs didn't. Now, I'm running a dual-processor machine that only linux can use effectively.
Linux's real market is in getting more use out of existing hardware. With OSX, you're buying hardware to support the OS. With Linux, you're getting an OS for free that runs on whatever hardware you already have. I can buy a new Super-GX-Pro-64-Turbo-Mega graphics card, and if it's not supported yet, it will be next month. I can also pull my old 386sx out of the closet, and it'll be supported too. Nobody but Linux can do that.
--
It's actually pretty simple: make the handbook say pretty much what you're saying here. You want to preserve your rights, while providing some assurance that you won't routinely spy on your employees "just in case". Perhaps something like this:
The company reserves the right to monitor or search all company property and equipment if improper or illegal conduct is suspected. However, all such monitoring or searching will be performed with at least one witness or explicit written instruction from at least two managers.
I'm not a lawyer. Run the above past one before using it.
--
Sorry, I typed too quickly.
HR46 <strong>did</strong> go through without the amendment. Hatch added the amendment in the senate, so it has to go back through the house. It has not done so yet, and will not do so before January.
--
The staffer that I talked to was a very nice fellow, and he did say that it's possible that it might have been slipped into one of the big omnibus appropriations bills, but HR 46 did not go through on its own.
--
In Linux land, it appears that projects fork for financial reasons. In BSD land, it appears that the forks that have happened were purely political reasons. I don't know what will happen. It's been 5 years since the last fork in the BSD camp. Why are you guys so fork paranoid?
I suspect that the question was rhetorical, but it deserves an answer. I'm putting it here, with the other fork comment, even though it wasn't written as a follow-up to that comment.
Simply put, it's (too) often used as an object lesson in Linux land. Whenever an argument gets too heated, someone jumps in with "if we keep acting like this, we'll end up like the BSDs." Meaning, I suppose, "fighting over a very tiny percentage of mindshare instead of working together to take over the world."
I suspect that Linux is headed toward a fork. Linus and Alan Cox have been leaving things out of the kernel (like a debugger) that a lot of people want. As there's no charter or formal organizational structure, I think that a coup of some sort is inevitable. When it happens, the interest in the Net/Open split will rise to a crescendo.
I have friends who are OpenBSD advocates, and others who are NetBSD advocates. To hear each side talk, the other side writes crappy code between bouts of trying to ruin BSD for everybody. It's depressing, particularly when I think about what could happen if their talents could be combined. Or, if they would just shut up, stop sniping at each other, and code.
I'd love to see some sort of cross-bsd advocacy organization to help users take that middle step. Help with porting of cool shit between the BSDs. Make generic cross-BSD documentation. Help people decide which OS and user/developer community is right for them. etc.
Unfortunately, that requires a friendlier attitude than I often see between the BSDs. Charges of "code theft" particularly frustrate me. That's the whole damned point of open source: Seeing the good stuff, learning from it, and using it.
--
Then he disagrees with almost every other typesetting usability study and style guide in existance. Perhaps his studies are based on sales sites (where there are lots of proper names) or it's an issue with the low resolution of computer monitors (where the serifs are "extra junk" rather than visual cues).
I think that the enemy of the good for onscreen body font selection is the unconventional.
After reading this a few times, I agree with you. For me, "conventional" is the user's default browser font(s).
--
Text should be in a table with a width of approx 200 - 500 pxls.
Let people decide this with their browsers, and never specify sizes in pixels. It looks awful on small monitors (say, PDAs, or Grandma's 640x480 monitor), and it's awful AND hard to read on a 1600x1200 display.
Do NOT put large amounts of text into a single, monolithic table. This may cause a user's browser to have to wait for the whole page to be loaded until they see any text.
This is a government web site, not a sales site. The goal is complete and accurate information, not loading speed. You need to realize that there are some people who HAVE to use special browsers (blind, etc.), and there are others who just don't want to use IE or Netscape, and these users would rather have all of their information in a single block rather than having their browser say "left-brace table right-brace left-brace tee arr right-brace left-brace tee dee right-brace" etc. before and after each paragraph.
Use sans-serif fonts
No. Let the user choose his own fonts in his browser. You're wrong about serifs and readability. Sans-serif is easier to read when the words are unfamiliar (proper nouns, technical jargon, etc.). Serifed fonts are easier to read for normal text, so long as the reader understands the words that are being used.
Give links for a zip-file of all text
There are many people, particularly in this august forum, who do not use windows. For these people, zip files are an inconvenience. Providing plain text files is a good idea, though.
--
barneyfoo or Mojo Jojo?
You make the call.
--
I've yet to find any claims that weren't obviouly biased (Open people saying that Open is better, Free people saying that Free is better, etc.). I think of myself as a Linux guy, but I like to play with all of the BSDs.
My own perceptions:
FreeBSD is nifty, and accepts code almost as liberally as Linux. That is, poorly written but functional is acceptable. This tends to result in FreeBSD having more nifty features that work before any of the other BSDs. However, the design is very evolutionary and distributed, and some bits of the code are just plain scary. Broken things that lots of people care about (like speed issues) are fixed quickly. Broken things that not many people care about tend to be ignored.
NetBSD contains the sort of code that'd make CS professors proud. It's clean and well-documented, and there's a lot of thought given to design and the larger picture. Like a CS project, though, it tends to be slow, as the most intuitive way to do things is often not the fastest. There are also times when the "run on anything" focus gets in the way of maximum performance.
OpenBSD audits their code for security, and the auditing gets rid of the worst of the poorly written code, but sometimes, the most secure design is horrifically unintuitive. The newer bits (like OpenSSH) show this the most: you'll need to make a sanity check after looking at some bits of that code. I really REALLY like the emphasis on security, though. It feels a little bit slower than FreeBSD, but not as slow as NetBSD. I have no hard numbers to back me up, just personal perception.
--
A lot of people know that OpenBSD forked from NetBSD, and there's still some animosity between the two groups. Personally, I think that the competition has helped both groups (NetBSD now ships with far fewer open services, for example).
Egos are delicate things, but do you see any chance for greater cooperation in the future, or do you see more forking and division as inevitable?
--
I erred. It's Source Safe, not Dev Studio, that has the ability to send check-ins (which are usually from Dev Studio) to outlook clients.
Writing a script that checks in a file in CVS and mails a diff to a list of addresses is trivial.
--
Exchange has two "advantages" over it's competitors: it's easy to set up (compared to Solaris, sendmail, imap), and it presents a uniform interface for users.
The first isn't an issue for you since you already have Solaris et al. set up.
As for the second, there's no particular functionality that Exchange/Outlook provides that isn't handled by other, separate programs. That's just a matter of user education. You can run Netscape/CS&T's calendar server on the Solaris machine, if it's calendaring you want. There are some weird hooks into Outlook from some other MS products (DevStudio, for example) that can be replicated pretty easily with CVS and a shell script.
You're probably aware of the disadvantages. HA isn't an option: it WILL crash. You'll need a dedicated NT sysadmin if you don't already have one. Preferrably one who's had to rebuild an Exchange server after it's crashed (which can be a brutal, time consuming job) and not a fresh "I just got my MCSE so I must be smart" type. Expect to have planned outages weekly to reboot "just in case", because otherwise the monthly crashes will be unscheduled and will take significantly loger to recover from. The exchange box should be a really really beefy single CPU machine with as much memory and disk as can be managed (as in, it'll cost as much as a Sun), and nothing except Exchange should run on it, to reduce the frequency of crashes.
--
One of the critical concepts in the american voting system is anonymity. The current system, for all its flaws, achieves this. They know that I voted, but they don't know who I voted for. This was done because people in power (at any level: bosses, politicians, even husbands) were able to force people to vote one way or another by retaliating if someone voted "incorrectly."
A lot of the "vote on the internet" stuff that you see doesn't have this anonymity. Electronic booths to replace the levers and punchcards are a good idea. Voting booths that might permit traceable votes aren't. If we're worried about people making it to the polls, we need to look at the absentee ballot handling (Oregon has a fantastic system for this) and perhaps we should declare voting day a national holiday and strongly discourage businesses from remaining open.
--