Then your problem is not with the IT folks doing the actual support work, rather the management structure that hasn't built a proper payback infrastructure in the organization.
Having done my share of supporting all manner of configuration, being able to devote the proper time to figuring the oddball problem is actually interesting so long as you're not going to get bit in the ass because all the time spent doing that simply means you now have that much more work not done when performance review time come up. Billable hours blunt those questions about why you'd fix the weird unsupported config problem when ten people with standard config require your attention.
It's resource economics and timing of connection blocking:
With spamhaus
1) Network connection is attempted and accepted by the mail server (a small amount of bandwidth and cpu). 2) A DNS lookup is made by the mail server for the incoming connection (DNS udp packets are relatively cheap -- a small amount of bandwidth and CPU used) 3) If the lookup exists in spamhaus, the mail server responds with a 550 error message (small amount of bandwidth and CPU)
Without spamhaus
1) Network connection is attempted and accepted (same as above) 2) One or more messages are sent over the network connection (much more bandwidth) 3) Possibly, those messages are checked by content filters top see if they are spam (MUCH higher CPU and memory costs -- content filtering isn't cheap) 4) Accepted or rejected...accepting costs more than rejecting.
The good thing about DNS RBLs is that they block the connection prior to any message being sent across. They are based entirely on the recorded behavior of the incoming IP address.
So, without spamhaus or a similar blocklist, the amount of CPU and storage necessary to keep email going is much higher than with spamhaus.
Did you actually watch it? Deanna turns into a frog (or immaculately conceives or turns into an old woman or senses hostility), Picard frets over moral issues, Riker is superfluous and Data (Spock Part II) and Wonder Boy Wesley save the day?
TNG had the advantage of being the only SF series on in the late 80s/early 90s. But it was by no means excellent. DS9 was a better Star Trek. B5 had acting that was just as bad, but a better storyline.
SG-1 is good. Not Battlestar Galactica good, but a good thing to watch.
Storage Area Network solutions are not under the $1/GB. Running a network filesystem (NFS, SMB, Coda, etc) are running a local filesystem over networked storage are two different things, fulfilling two different needs.
iSCSI and AoE don't necessary directly benefit the small/home server market, but for the things that SANs are traditionally used for (data replication across geographically separated sites without any changes to the application software) there could end up being a big win in cost.
CAS works in small environments. Indiana University is using it and finding that it doesn't scale. It can't be scaled horizontally over multiple servers and doesn't fail gracefully.
Single sign-on systems are difficult to get working with software systems that are not designed for them. I'd be wary of going down that path. It is a quagmire of time and resources to get running and keep running.
Gates isn't only stating that DVDs will be obsolete. All his objections to DVDs work for any physical media -- they can be lost and they can be damaged.
The only delivery mechanism that is not subject to these constraints are network delivery of licensed material. It is never damaged or destroyed because you don't get to keep a copy of the material that was purchased. If you want to use the material again, within the constraints of your license, you fetch it from a network server again. Can't be lost, can't easily be destroyed.
There are other constraints, I think, that would keep this from becoming a reality. The most obvious is that with every purchase of a physical media (CD, DVD) you increase the amount of local storage available to the consumer. If you have a caching media server, it is possible to overrun the cache and degrade performance. If your local cache of media is a physical object that makes the data local, that is less of a problem.
There are legal and moral constraints too, but that is a whole other discussion.
Business types are afraid of OSS mostly for the fact that it's "unsupported." To them, support doesn't mean having developers on hand to fix problems so much as it does having someone to blame when things go wrong. As long as someone else is fiscally responsible for their technology problems, their customers/shareholders are happy.
Here's the hole in that theory: no one has ever successfully sued Microsoft for technology problems with MS products. Worms, viruses, etc have all cost reported billions of dollars (real cost unknown, but obviously significant), yet MS does not bear the consequences of those losses.
The question of whether it is possible for us (as a species) to build completely error free systems (thus making it feasable to hold vendors responsible for mistakes) is for another time. The possibility that software is more abstract and thus more complex for humans than any other form of commercial engineering maybe the case.
This is not to let MS off the hook. In my dealings with them, the company in the past has tended to let the marketers write the program specifications, often over the objections of actual engineers. The difference in perspective between a salesperson and an engineer is significant with regards to long term security and reliability.
Isn't this the same argument that used for the metric system?
I mean, really, the parallels are there. The rest of the world uses a superior system that is standardized across national boundaries, and the US continues using an older, less useful system due to a combination of stubborness and inertia...
Hmmm. Really reminds me more of J. Edgar Hoover. But you are right. Better we should take our lessons from across the oceans than from the fascists in our own backyard.
(not that Stalin and Beria were nice guys, mind you -- it's just that there aren't mass executions in the U.S. yet)
My exposure to Netware is limited. Perhaps it does work well there. I've never tried on that platform. I did a quick google and didn't find anything on the locking semantics of a Netware volume. Do you have any pointers to resources.
The difference between multiple processes and threads on a single OS and multiple clients across the network is the level of atomcity in the locking operation. Single OS locking problems are well solved and work efficiently. This is not the general case with network locking. A spinlock or a semaphore in the OS has atomic semantics built into it.
Please note that I didn't say it was impossible, or that partial solutions do not exist. Lockd for NFS does a partial job of solving the problem, but becomes ineffiecient and fails under load. Multimaster databases obviously have solved the problem (using the promise/commit model). The general solution has not, however, found its way into most networked filesystems.
Locking under any network filesystem, be it nfs, cifs, dfs, etc doesn't work well.
Here is the problem:
You have a single server and multiple clients. File locks are held in the OS of the local machine. In the OS of the local machine, you can lock a file or a section of a file, and be certain that it is an atomic operation -- i.e. between the start of the locking process and the end of the locking process, no changes have occurred to section being locked. During the locking operation, you can also be sure that no other lock will be granted on the data, or your attempt to lock will fail.
So, you try and do this with multiple network clients. First, no locking daemon currently available currently runs in such a way as to ensure atomicity of the locking operation. Since there is network latency and no atomic shared resource, you will get two processes claiming they hold the same lock.
So, how do you get past this. The two ways I know of are token passing and promise/commit systems. Token passing involves a single token that represents the resource being locked, and it is passed from client to client, introducing N way behavior between N clients or a single token manager. This is expensive and difficult to get right.
Promise/commit systems are what I believe most multi-master databases use. Also expensive and difficult to get right.
So where is this built? GPFS (an IBM SAN filesystem) has a token manager to handle that. I don't know how the Sistina GFS stuff handles locking. There are others -- SGI's CXFS and so on.
All that said, you don't run a database on a network filesystem if you care about the integrity of the data. In fact, unless you have application level checks (like qdir for mail stores), you don't run any sort of system with multiple writers on a network filesystem.
With Courier, you don't have to worry about the size of installation (number of mailboxes), but the theoretical maximum number of messages in a single folder. That is going to be your bottleneck in terms of performance. For every basic fetch of header (every opening of the mailbox in most clients -- pine and imp excepted), every file in the folder will be opened and parsed. It will kill both your IO and your CPU. Small mailboxes are fine -- if you plan on limitting quotas, you should have no problems.
As for running sendmail -- we also handle the central relays and there are features available in sendmail that are not available elsewhere. Milters are the current feature that no one else has, but there are also better ways to manage queues in sendmail than are readily available in postfix. We have to not only deliver mail to ourselve, but to a plethora of departmental servers that may or not be available. We are currently handling anywhere from 2 to 6 million messages through the relays daily.I ran qmail in test for a while, and foudn that the pipelining of processes was just too inefficient for a large scale site.
In any case, it is easier from a configuration management point of view to run the same software as the MTA everywhere we can.
I work for a major university with seven campuses and email supported centrally.
We currently support 180,000 users across 6 four way sparcs. We are somewhere close to 2 TB of mail data. We've been running with an average of 1 unscheduled downtime per year over the past five years.
We use sendmail + cyrus, with a few minor modications. We have no plans to move away from the cyrus imap server.
Cyrus (once set up) is a dream to take care of. Writing scripts to handle mailbox administration is done in perl (previosly in tcl) and you can set PAM up (or pwcheck if you are old school) to handle any authentication you need. There are web tools to do manual administration (check freshmeat.net) but in our environment, we accept account requests from a different department, and simply use a script to generate the account.
We run a modified Horde IMP with the UP imapproxy to handle webmail connections.
We currently average about 4 thousand concurrent logins to the IMAP servers themselves, across all clients (web, desktop, some pine, etc).
The current cyrus release will support a murder of IMAP servers, allowing you to use one namespace for multiple imap servers (you can spread your userbase across 15 imap servers -- imap1.domain.com to imap15.domain.com but only tell the clients to connect imap.domain.com) allowing you to add or remove machines from your pool by just moving the users from one machien to the next.
Over the years, we've tested UW, Courier, and various commercial IMAP implementations, and none has touched cyrus in terms of speed, reliability, and ease of administration. UW, even with the better mailbox drivers, is still slower, and generally (unless dealing with the MH driver which has its own limitations) still deals with everything as a single file, leading to some memory issues if you have several thousand users with political pull in your organization that don't want to delete anything.
Courier's maildir implementation also has problems with large mailboxes, as header indexes are generated from the mail data rather than cached, causing all files to be touched.
I understand that dovecot has taken a hybrid approach, caching header information while still using a maildir store. If header information is cached on local disk, the store can still be mounted via NFS. It is a good model, but we've found that IO is the bootleg in large email installations. NFS mailstores would give us flexibility with regards to redundant imap protocol servers, but the resource we are most trying to conserve (IO bandwidth) is still bottlenecked (theorectically at a single server IO throughput, realistically at NFS throughput speeds).
There is another project, dbmail (www.dbmail.org) that uses mysql as a mailstore. There are many gains possible using a database backend, but drawbacks as well...recovery of small amounts of data from backups is one. In any case, dbmail is not as mature as either UW or cyrus.
Mark Crispin (author of the IMAP protocol and the UW IMAP server) has said that cyrus is the race car of the IMAP world. Built for high performance -- the ease of administration is just something you get from free.
I should read the tech papers, but here's a guess...
A user authenticates to ADS, getting back authenitcation credentials...essentially the MS kerberos ticket.
That ticket can then be used to authenticate to the Rights Management Server. Here's the unclear part...does the Rights Management Server handle the ACLs and provide a single symmetic key to unlock the document, or does the RMS (wow -- irony) act as a key server and the document is created with asymmetric encryption with ACLs encoded in the document? Or some other scheme?
This isn't rocket science. If you can get ADS and the RMS to accept your credentials, then interop would be figuring out what encryption scheme is used. As the credentials could be obtained legally, reverse engineering would not necessarily circumventing the scheme.
However, the prevention of re-saving the file seems entirely unenforceable once anything is known of the file outside the MS environment. Indeed, a secondarly program with the proper credentials could copy the data without circumventing the RMS. Unless opening a DRM protected document disallowed other processes any processor time...
This is a tough problem, and I am certain that smart guys at MS have thought this stuff through, but I am also fairly certain that it is not thought through well enough. It seems only useful for preventing casual copying to data.
Where I attended college, this is how it played out:
1) MIS was a business degree with basic programming. The programming
2) CIS was a little more technical, but clearly the emphasis was on higher level programming (VB, macro stuff, COBOL) than on the nuts and bolts of computers.
3) CS had a heavy emphasis on software engineering, but there was significant coursework on how mechanized computation is implemented, ie processor design was taught as well as programming languages.
4) Computer Engineering was sort of a cross between Electrical Engineering and CS.
At my school, there was significant overlap between CompE and CS, to the point that we took many of the same core classes with regards to hardware. Near the end of the programs, final projects differed in implementation (CompE's had to build a simple computer via wire wrap and programmable arrays, CS majors had to write in software a SPARC similuator that would run compiled SPARC code).
For the record, I was graduated with a CS degree, went somewhere else for grad school, and found the the definition of CS is different depending on the department. My undergraduate work is much closer to what my grad advisors considered CompE work, where they spent much more time with the abstraction of computation away from the actual mechanisms -- predicate calculus rather than processor design. I initially hated it.
I found (after some time spent actually adminning (sp?) and programming for a living) that both phases of education have served me extremely well. The ability to abstract pieces of a large problem into discrete parts has been the best skill in my toolbox with regards to programming, while actually understanding the implmentation of processors and compilers has given me a leg up in terms of debugging both my code and vendor supplied software.
My advice to anyone starting out is to learn how to abstract and then get as technical as you can. The basics of computers are not going to change drastically for a good deal of time (no one is seriously considering a move away from Von Nuemann machines in their business plan), so if you know how computers work, the details of a programming language or an OS are just variations on a theme you already know. No matter what happens, it still just comes down to instructions on the code stack.
Then attend a trade school. Universities teach a broad range of subjects, and the best will always make you learn things you would've have chosen.
Trust me on this: I have a CS degree and most of a Masters in CS, and I've worked in the field for a good while. All those things that are directly important to your career are less important to it than you think. You end up learning most of what your career requires while you are working, because you need it.
It is the information (and more importantly, how to place any new information in a larger context) that can make you special with regards to what you can do in yor career. And that is what making students learn about a broad range of subjects teaches.
I used to think as you do, when I was still an undergrad. When I entered the real world, I found that what I thought would get me ahead while I was a student was way off base.
Paper money in and of itself has only the value of the paper it is printed on.
A cashless society doesn't require any more faith than currency that is no longer on the gold standard for actual value.
As for record keeping, that is a much mroe valid point. People are not going to be down with being taxed on winning a five dollar bet on a football game, or on the proceeds from a garage sale. But then, people would just switch to other way of trading value if they wanted to avoid a record of the transaction. If people are too inconvenienced by rules, they'll just not follow them...
I think the point of the comment was that you could enforce this law, in theory. In theory, it is possible to hire enough people to do door to door searches for modified PlayStations. It is an idea which is understood, and in some context does match reality. The hypothesis is that it is possible to enforce the law.
In practice, it is very far too expensive to implement. The theory still exists, it is just costs more than the Australian government is likely willing to spend. The hypothesis has not been disproven, just (possibly) written off an not economical.
It appears to me that there is nothing wrong with the use of the word theory in this context.
Perhaps I am misunderstanding you. If that is the case, I apologize.
Oil companies can put a stranglehold on moving products, on heating homes, on production of electricity.
Time/Warner can enter the homes of nearly every consumer in western economies, to advertise and shape their expectations, both commercially and politically. How much of an American's viewpoint is formed by what they learn on CNN? Or through Time magazine?
Companies with real power shape the policies of a nation by supporting candidates with contributions, and directing perception of politicians and policy.
Microsoft does not do these things. Bill Gates is worth a ton of money, but how much of that is liquid and available for use in these ways? How much can MS actually affect public policy?
They're trying, I'll give them that. But does anyone really think that something with the name MSNBC is not going to be biased? It doesn't matter if they are completely above board; using the name as a method of advertising for MS gives the perception of bias.
In truth, the amount of real power outside the tech industry that MS wields is limited to its liquid assets. They just aren't a real player.
Don't believe the tech hype. There are really powerful companies out there, and Microsoft is among the smaller of them.
Try AOL-Time/Warner. Try Monsanto. Try the Royal Dutch Shell companies. Those organizations have power the way MS can only dream of. Given that Microsoft is the current 500 lb gorilla of the tech world, don't think that it translates to the rest of the econmomy.
The headers are stored in a db file for quick searching, a cache file, and and index file is kept. It does store each individual message in a file, so a decent filesystem is essential for an enterprise operation.
It ends up working incredibly well. The University where I work handles 120,000 accounts, and the software side never has a problem.
Slashdot Mirror
Then your problem is not with the IT folks doing the actual support work, rather the management structure that hasn't built a proper payback infrastructure in the organization.
Having done my share of supporting all manner of configuration, being able to devote the proper time to figuring the oddball problem is actually interesting so long as you're not going to get bit in the ass because all the time spent doing that simply means you now have that much more work not done when performance review time come up. Billable hours blunt those questions about why you'd fix the weird unsupported config problem when ten people with standard config require your attention.
It's resource economics and timing of connection blocking:
With spamhaus
1) Network connection is attempted and accepted by the mail server (a small amount of bandwidth and cpu).
2) A DNS lookup is made by the mail server for the incoming connection (DNS udp packets are relatively cheap -- a small amount of bandwidth and CPU used)
3) If the lookup exists in spamhaus, the mail server responds with a 550 error message (small amount of bandwidth and CPU)
Without spamhaus
1) Network connection is attempted and accepted (same as above)
2) One or more messages are sent over the network connection (much more bandwidth)
3) Possibly, those messages are checked by content filters top see if they are spam (MUCH higher CPU and memory costs -- content filtering isn't cheap)
4) Accepted or rejected...accepting costs more than rejecting.
The good thing about DNS RBLs is that they block the connection prior to any message being sent across. They are based entirely on the recorded behavior of the incoming IP address.
So, without spamhaus or a similar blocklist, the amount of CPU and storage necessary to keep email going is much higher than with spamhaus.
Star Trek TNG excellent?
Did you actually watch it? Deanna turns into a frog (or immaculately conceives or turns into an old woman or senses hostility), Picard frets over moral issues, Riker is superfluous and Data (Spock Part II) and Wonder Boy Wesley save the day?
TNG had the advantage of being the only SF series on in the late 80s/early 90s. But it was by no means excellent. DS9 was a better Star Trek. B5 had acting that was just as bad, but a better storyline.
SG-1 is good. Not Battlestar Galactica good, but a good thing to watch.
Storage Area Network solutions are not under the $1/GB. Running a network filesystem (NFS, SMB, Coda, etc) are running a local filesystem over networked storage are two different things, fulfilling two different needs.
iSCSI and AoE don't necessary directly benefit the small/home server market, but for the things that SANs are traditionally used for (data replication across geographically separated sites without any changes to the application software) there could end up being a big win in cost.
CAS works in small environments. Indiana University is using it and finding that it doesn't scale. It can't be scaled horizontally over multiple servers and doesn't fail gracefully.
Single sign-on systems are difficult to get working with software systems that are not designed for them. I'd be wary of going down that path. It is a quagmire of time and resources to get running and keep running.
The only delivery mechanism that is not subject to these constraints are network delivery of licensed material. It is never damaged or destroyed because you don't get to keep a copy of the material that was purchased. If you want to use the material again, within the constraints of your license, you fetch it from a network server again. Can't be lost, can't easily be destroyed.
There are other constraints, I think, that would keep this from becoming a reality. The most obvious is that with every purchase of a physical media (CD, DVD) you increase the amount of local storage available to the consumer. If you have a caching media server, it is possible to overrun the cache and degrade performance. If your local cache of media is a physical object that makes the data local, that is less of a problem.
There are legal and moral constraints too, but that is a whole other discussion.
Here's the hole in that theory: no one has ever successfully sued Microsoft for technology problems with MS products. Worms, viruses, etc have all cost reported billions of dollars (real cost unknown, but obviously significant), yet MS does not bear the consequences of those losses.
The question of whether it is possible for us (as a species) to build completely error free systems (thus making it feasable to hold vendors responsible for mistakes) is for another time. The possibility that software is more abstract and thus more complex for humans than any other form of commercial engineering maybe the case.
This is not to let MS off the hook. In my dealings with them, the company in the past has tended to let the marketers write the program specifications, often over the objections of actual engineers. The difference in perspective between a salesperson and an engineer is significant with regards to long term security and reliability.
Errr...heroes is the plural, not heros.
Isn't this the same argument that used for the metric system?
I mean, really, the parallels are there. The rest of the world uses a superior system that is standardized across national boundaries, and the US continues using an older, less useful system due to a combination of stubborness and inertia...
Hmmm. Really reminds me more of J. Edgar Hoover. But you are right. Better we should take our lessons from across the oceans than from the fascists in our own backyard.
(not that Stalin and Beria were nice guys, mind you -- it's just that there aren't mass executions in the U.S. yet)
My exposure to Netware is limited. Perhaps it does work well there. I've never tried on that platform. I did a quick google and didn't find anything on the locking semantics of a Netware volume. Do you have any pointers to resources.
The difference between multiple processes and threads on a single OS and multiple clients across the network is the level of atomcity in the locking operation. Single OS locking problems are well solved and work efficiently. This is not the general case with network locking. A spinlock or a semaphore in the OS has atomic semantics built into it.
Please note that I didn't say it was impossible, or that partial solutions do not exist. Lockd for NFS does a partial job of solving the problem, but becomes ineffiecient and fails under load. Multimaster databases obviously have solved the problem (using the promise/commit model). The general solution has not, however, found its way into most networked filesystems.
Locking under any network filesystem, be it nfs, cifs, dfs, etc doesn't work well.
Here is the problem:
You have a single server and multiple clients. File locks are held in the OS of the local machine. In the OS of the local machine, you can lock a file or a section of a file, and be certain that it is an atomic operation -- i.e. between the start of the locking process and the end of the locking process, no changes have occurred to section being locked. During the locking operation, you can also be sure that no other lock will be granted on the data, or your attempt to lock will fail.
So, you try and do this with multiple network clients. First, no locking daemon currently available currently runs in such a way as to ensure atomicity of the locking operation. Since there is network latency and no atomic shared resource, you will get two processes claiming they hold the same lock.
So, how do you get past this. The two ways I know of are token passing and promise/commit systems. Token passing involves a single token that represents the resource being locked, and it is passed from client to client, introducing N way behavior between N clients or a single token manager. This is expensive and difficult to get right.
Promise/commit systems are what I believe most multi-master databases use. Also expensive and difficult to get right.
So where is this built? GPFS (an IBM SAN filesystem) has a token manager to handle that. I don't know how the Sistina GFS stuff handles locking. There are others -- SGI's CXFS and so on.
All that said, you don't run a database on a network filesystem if you care about the integrity of the data. In fact, unless you have application level checks (like qdir for mail stores), you don't run any sort of system with multiple writers on a network filesystem.
With Courier, you don't have to worry about the size of installation (number of mailboxes), but the theoretical maximum number of messages in a single folder. That is going to be your bottleneck in terms of performance. For every basic fetch of header (every opening of the mailbox in most clients -- pine and imp excepted), every file in the folder will be opened and parsed. It will kill both your IO and your CPU. Small mailboxes are fine -- if you plan on limitting quotas, you should have no problems.
As for running sendmail -- we also handle the central relays and there are features available in sendmail that are not available elsewhere. Milters are the current feature that no one else has, but there are also better ways to manage queues in sendmail than are readily available in postfix. We have to not only deliver mail to ourselve, but to a plethora of departmental servers that may or not be available. We are currently handling anywhere from 2 to 6 million messages through the relays daily.I ran qmail in test for a while, and foudn that the pipelining of processes was just too inefficient for a large scale site.
In any case, it is easier from a configuration management point of view to run the same software as the MTA everywhere we can.
I work for a major university with seven campuses and email supported centrally.
We currently support 180,000 users across 6 four way sparcs. We are somewhere close to 2 TB of mail data. We've been running with an average of 1 unscheduled downtime per year over the past five years.
We use sendmail + cyrus, with a few minor modications. We have no plans to move away from the cyrus imap server.
Cyrus (once set up) is a dream to take care of. Writing scripts to handle mailbox administration is done in perl (previosly in tcl) and you can set PAM up (or pwcheck if you are old school) to handle any authentication you need. There are web tools to do manual administration (check freshmeat.net) but in our environment, we accept account requests from a different department, and simply use a script to generate the account.
We run a modified Horde IMP with the UP imapproxy to handle webmail connections.
We currently average about 4 thousand concurrent logins to the IMAP servers themselves, across all clients (web, desktop, some pine, etc).
The current cyrus release will support a murder of IMAP servers, allowing you to use one namespace for multiple imap servers (you can spread your userbase across 15 imap servers -- imap1.domain.com to imap15.domain.com but only tell the clients to connect imap.domain.com) allowing you to add or remove machines from your pool by just moving the users from one machien to the next.
Over the years, we've tested UW, Courier, and various commercial IMAP implementations, and none has touched cyrus in terms of speed, reliability, and ease of administration. UW, even with the better mailbox drivers, is still slower, and generally (unless dealing with the MH driver which has its own limitations) still deals with everything as a single file, leading to some memory issues if you have several thousand users with political pull in your organization that don't want to delete anything.
Courier's maildir implementation also has problems with large mailboxes, as header indexes are generated from the mail data rather than cached, causing all files to be touched.
I understand that dovecot has taken a hybrid approach, caching header information while still using a maildir store. If header information is cached on local disk, the store can still be mounted via NFS. It is a good model, but we've found that IO is the bootleg in large email installations. NFS mailstores would give us flexibility with regards to redundant imap protocol servers, but the resource we are most trying to conserve (IO bandwidth) is still bottlenecked (theorectically at a single server IO throughput, realistically at NFS throughput speeds).
There is another project, dbmail (www.dbmail.org) that uses mysql as a mailstore. There are many gains possible using a database backend, but drawbacks as well...recovery of small amounts of data from backups is one. In any case, dbmail is not as mature as either UW or cyrus.
Mark Crispin (author of the IMAP protocol and the UW IMAP server) has said that cyrus is the race car of the IMAP world. Built for high performance -- the ease of administration is just something you get from free.
What are we really talking about here?
I should read the tech papers, but here's a guess...
A user authenticates to ADS, getting back authenitcation credentials...essentially the MS kerberos ticket.
That ticket can then be used to authenticate to the Rights Management Server. Here's the unclear part...does the Rights Management Server handle the ACLs and provide a single symmetic key to unlock the document, or does the RMS (wow -- irony) act as a key server and the document is created with asymmetric encryption with ACLs encoded in the document? Or some other scheme?
This isn't rocket science. If you can get ADS and the RMS to accept your credentials, then interop would be figuring out what encryption scheme is used. As the credentials could be obtained legally, reverse engineering would not necessarily circumventing the scheme.
However, the prevention of re-saving the file seems entirely unenforceable once anything is known of the file outside the MS environment. Indeed, a secondarly program with the proper credentials could copy the data without circumventing the RMS. Unless opening a DRM protected document disallowed other processes any processor time...
This is a tough problem, and I am certain that smart guys at MS have thought this stuff through, but I am also fairly certain that it is not thought through well enough. It seems only useful for preventing casual copying to data.
"Mr Stallman is free to say whatever he wants, as we live in a country of First Amendment protections."
> Would have been nice to get standard screenshots option as well.
http://oeone.com/products/screenshots.html
I've done a fair bit of kerberos programming, and the available documnetation leaves a lot to be desired. What I'd like to see are:
Running Kerberos
Programming Kerberos
Initgrating Kerberos 5 and MS Active Directory
Where I attended college, this is how it played out:
1) MIS was a business degree with basic programming. The programming
2) CIS was a little more technical, but clearly the emphasis was on higher level programming (VB, macro stuff, COBOL) than on the nuts and bolts of computers.
3) CS had a heavy emphasis on software engineering, but there was significant coursework on how mechanized computation is implemented, ie processor design was taught as well as programming languages.
4) Computer Engineering was sort of a cross between Electrical Engineering and CS.
At my school, there was significant overlap between CompE and CS, to the point that we took many of the same core classes with regards to hardware. Near the end of the programs, final projects differed in implementation (CompE's had to build a simple computer via wire wrap and programmable arrays, CS majors had to write in software a SPARC similuator that would run compiled SPARC code).
For the record, I was graduated with a CS degree, went somewhere else for grad school, and found the the definition of CS is different depending on the department. My undergraduate work is much closer to what my grad advisors considered CompE work, where they spent much more time with the abstraction of computation away from the actual mechanisms -- predicate calculus rather than processor design. I initially hated it.
I found (after some time spent actually adminning (sp?) and programming for a living) that both phases of education have served me extremely well. The ability to abstract pieces of a large problem into discrete parts has been the best skill in my toolbox with regards to programming, while actually understanding the implmentation of processors and compilers has given me a leg up in terms of debugging both my code and vendor supplied software.
My advice to anyone starting out is to learn how to abstract and then get as technical as you can. The basics of computers are not going to change drastically for a good deal of time (no one is seriously considering a move away from Von Nuemann machines in their business plan), so if you know how computers work, the details of a programming language or an OS are just variations on a theme you already know. No matter what happens, it still just comes down to instructions on the code stack.
Then attend a trade school. Universities teach a broad range of subjects, and the best will always make you learn things you would've have chosen.
Trust me on this: I have a CS degree and most of a Masters in CS, and I've worked in the field for a good while. All those things that are directly important to your career are less important to it than you think. You end up learning most of what your career requires while you are working, because you need it.
It is the information (and more importantly, how to place any new information in a larger context) that can make you special with regards to what you can do in yor career. And that is what making students learn about a broad range of subjects teaches.
I used to think as you do, when I was still an undergrad. When I entered the real world, I found that what I thought would get me ahead while I was a student was way off base.
Paper money in and of itself has only the value of the paper it is printed on.
A cashless society doesn't require any more faith than currency that is no longer on the gold standard for actual value.
As for record keeping, that is a much mroe valid point. People are not going to be down with being taxed on winning a five dollar bet on a football game, or on the proceeds from a garage sale. But then, people would just switch to other way of trading value if they wanted to avoid a record of the transaction. If people are too inconvenienced by rules, they'll just not follow them...
I think the point of the comment was that you could enforce this law, in theory. In theory, it is possible to hire enough people to do door to door searches for modified PlayStations. It is an idea which is understood, and in some context does match reality. The hypothesis is that it is possible to enforce the law.
In practice, it is very far too expensive to implement. The theory still exists, it is just costs more than the Australian government is likely willing to spend. The hypothesis has not been disproven, just (possibly) written off an not economical.
It appears to me that there is nothing wrong with the use of the word theory in this context.
Perhaps I am misunderstanding you. If that is the case, I apologize.
What does MS have that companies actually need?
Oil companies can put a stranglehold on moving products, on heating homes, on production of electricity.
Time/Warner can enter the homes of nearly every consumer in western economies, to advertise and shape their expectations, both commercially and politically. How much of an American's viewpoint is formed by what they learn on CNN? Or through Time magazine?
Companies with real power shape the policies of a nation by supporting candidates with contributions, and directing perception of politicians and policy.
Microsoft does not do these things. Bill Gates is worth a ton of money, but how much of that is liquid and available for use in these ways? How much can MS actually affect public policy?
They're trying, I'll give them that. But does anyone really think that something with the name MSNBC is not going to be biased? It doesn't matter if they are completely above board; using the name as a method of advertising for MS gives the perception of bias.
In truth, the amount of real power outside the tech industry that MS wields is limited to its liquid assets. They just aren't a real player.
Most powerful? Most influential?
Don't believe the tech hype. There are really powerful companies out there, and Microsoft is among the smaller of them.
Try AOL-Time/Warner. Try Monsanto. Try the Royal Dutch Shell companies. Those organizations have power the way MS can only dream of. Given that Microsoft is the current 500 lb gorilla of the tech world, don't think that it translates to the rest of the econmomy.
That is pretty much what cyrus does.
The headers are stored in a db file for quick searching, a cache file, and and index file is kept. It does store each individual message in a file, so a decent filesystem is essential for an enterprise operation.
It ends up working incredibly well. The University where I work handles 120,000 accounts, and the software side never has a problem.