KCLUG

kclug@kclug.org

3239 discussions

Re: M$ Litigation against Linux
by Luke -Jr 13 Oct '07

13 Oct '07

On Friday 12 October 2007, you wrote: > On 10/12/07, Luke -Jr <luke(a)dashjr.org> wrote: > > On Friday 12 October 2007, Arthur Pemberton wrote: > > > On 10/12/07, Jestin Stoffel <jestin.stoffel(a)gmail.com> wrote: > > > > On Fri, 2007-10-12 at 11:25 -0700, Julie wrote: > > > > > Some of you may find the msg threads to this article a bit > > > > > "interesting". ;) > > > > > > > > > > http://blogs.zdnet.com/Berlind/?p=833&tag=nl.e589 > > > > > > > > The conspiracy theory that Microsoft is behind this suit falls > > > > somewhere between alarmist nonsense and obviousness. > > > > > > It could just be a coincidence that this happened right on the heals > > > of Balmer's latest threats. And it could just be a coincidence that > > > the patent holder if isn't also suing Microsoft. > > > > Microsoft doesn't violate it, unless that's something new in Vista. > > Aren't we talking about virtual desktops? Or did I misunderstand the > scope of the patent? Indeed, a concept foreign to Windows.

3 3

TechRepublic Blogs: A desktop Linux success story
by Julie 13 Oct '07

13 Oct '07

http://blogs.techrepublic.com.com/opensource/?p=116 Anyone have the e-mail addy to the KC Library IT Dept.? ...hehehe ]:) Julie @};- P.S.: The previous link I submitted (entitled TechRepublic Blogs: Open source or proprietary: Which software model is better for the consumer?) was the WRONG one. <blushing beet red> grrrrr!!!!!! --------------------------------- Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.

1 0

TechRepublic Blogs: Open source or proprietary: Which software model is better for the consumer?
by Julie 13 Oct '07

13 Oct '07

http://blogs.techrepublic.com.com/opensource/?p Anyone have the e-mail addy to the KC Library IT Dept.? ...hehehe ]:) Julie @};- --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today!

2 1

M$ Litigation against Linux
by Julie 13 Oct '07

13 Oct '07

Hi, Some of you may find the msg threads to this article a bit "interesting". ;) http://blogs.zdnet.com/Berlind/?p=833&tag=nl.e589 ENJOY! :D Julie @};-- --------------------------------- Pinpoint customers who are looking for what you sell.

4 4

book review of "Beuitiful Code: ..."
by David Nicol 12 Oct '07

12 Oct '07

slashdot has rejected my work. Oh well, here it is. **************************** Beautiful Code is a collection of thirty-three essays by notable computer programmers, all dared by editors Greg Wilson and Andy Oram to hold forth about a piece of source code they have found notably beautiful, apparently with intention of producing what may become a standard computer science textbook. Such an experiment has not been carried out before. Were Don Knuth dead, this book would probably be dedicated to his memory. Beautiful Code collects "cultural wisdom" of computer programmers. If one were to consider The Art of Computer Programming to be something of a Pentateuch, Beautiful Code could the accompanying Midrash. Having obtained an e-copy from O'Reilly and processed it with pdf2txt and then run <code> grep -ci knuth Chapter*.txt</code>, I found that not everyone mentioned Knuth. Those who did have a K number greater than zero by their name in the synopses below. (Asterisks before the author's name represent other chapters mentioning the author.) Speaking of experiments, O'reilly is trying to develop an online community based on the book, with <a href="http://beautifulcode.wiki.oreilly.com/wiki/index.php/Main_Page">a wiki.</a> I had several programming projects prioritized ahead of writing this book review, but after leafing through the six hundred pages and reading a few of the pieces in it at random I realized that my professional work would benefit from making reading it cover to cover my primary free-time action item. To be systematic and thorough, here are quick summaries of the essays, which are more prolix than the editor's version of the same exercise in the preface. Proceeding in this fashion is really horrible book review practice, but there really isn't any cleaner way to approach this particular text. *** Brian Kernighan (K0) discusses Rob Pike's minimal regular expression engine optimized for pedagogy. Karl Fogel (K0) tells the origin story of Subversion's "delta editor" internal interface, including an abandoned branch. He introduces a human-factors aspect to software beauty: by having a strongly defined interface, development time which might be squandered on debating interface points can be put to more productive use. ** Jon Bentley (K4), the author of Programming Pearls, holds forth about quicksort, instrumenting quicksort, and generating mathematical forumlae which give the same results. His essay nicely demonstrates the tension between procedural (pseudocode) and descriptive (mathematics) language. Tim Bray (K0), writing in a tone suitable for a more general audience, uses Ruby's regexps to analyze his Apache server logs from his blog, which he encourages the reader to check out, to build a case for his suspicion that Google uses binary search. * Elliotte Rusty Harold (K1) draws on experience writing XML verifiers to reinforce the truism that early passes at a problem should focus on correctness, saving speed for later. Michael Feathers (K0) explains his appreciation for Ward Cunningham's FIT Java testing framework's noncompliance against Java coders' rules of thumb, revealing a tension between closed (final classes, designed-in hooks and extension points) and open (working stub base classes) approaches to designing for extensibility. FIT-derived systems take HTML system documentation with tests embedded in it in tables as input and fill in one table cell with a pass/fail result. By carefully selecting what to hold constant and deferring extensibility to authors of derived classes, FIT allows Java developers, jaded and wounded by corporate infighting, to appreciate the fundamental elegance of a solid, basic, O-O approach. * Alberto Savoia (K1) plays fast and loose with math jargon. He discusses JUnit as an introduction to an exploration of how to test a binary search function for correctness. He performs a math proof -- claiming that a conclusion follows from implications of known-true axioms -- without calling it that, and a few pages later uses the word "induction" in the non-mathematical sense. He gives us a quick course in software testing best practices, including smoke testing, boundary testing, and what he calls "test theories" which are statements made about what the tested system is supposed to do, and some techniques for deriving additional test theories off the "happy path." Apparently 2006 was the year that data sets reached the size where the (a+b)/2 method of finding the midpoint between a and b started overflowing using signed 32-bit integers, which wreaked all kinds of weird havoc. Charles Petzold (K0) uses and endorses dynamic code generation for efficient image processing, reminiscing about the feats of the team who wrote Windows 1.0 in 8086 assembly language and applying similar techniques in his C# code thanks to the System.Reflection.Emit namespace. The results aren't easy on the eyes, but they run in a quarter of the time of equivalent code that makes decisions inside loops. It is not clear if the MSIL compiler is going to be so brazen as to perform loop unrolling on bytecodes emanating from ILGenerator objects; if not, I expect that the optimal acceleration of the dynamic method would occur with the loops unrolled into a modified Duff's device large enough to use almost all of the CPU cache. That would remove many loop bounds comparisons, which aren't that many instructions compared with the operation being performed on each pixel, but which may necessitate CPU pipeline stalls. To save another two percent of the time, and possibly hurt general system performance during the operation. Small processes take less effort to switch between. So never mind. Unless you want to benchmark it for something to do. Douglas Crockford (K1), who explains why LISP has never been accepted by the mainstream, and why the LISP community doesn't care, proposes to use a technique from a 1973 paper (anticipating object orientation, no less) by Vaughn Pratt ("Top Down Operator Precedence") that modified a technique published by Robert W. Floyd (for whom Knuth wrote a glowing eulogy) to write a parser that can process a subset of ECMA-262 (a.k.a. Javascript) entirely within that subset, which includes functions, objects, and JSON literals. It's all about the left binding power. And the "nud" and the "led," terms which when given to a search engine yield a slightly easier-going version of chapter nine. Null denotation and left denotation. Truthy and falsy. Don't repeat yourself, write a macro. A parser yields a parse tree, and hands that off to something else. A proposal for accommodating the needs of both language designers who want to reserve a lot of symbols and programmers who don't want to have to synonymize around them. Would extending Pratt's technique to support languages where not everything is a functional expression really be as easy as Crockford makes it look? Later in the book, R. Kent Dybvig (K0) explains how Scheme's syntax-case macro expander lets the programmer forget the whole deal about using quasi-reserved names in macros, because it abstracts them out for you, while offering an extra-special syntax for when you really truly do want to interfere with the internal operation of a macro. I am very pleased that O'Reilly sent me this book to review while I have been working on a macro system for Perl, and having read the Dybvig and Crockford articles, Macrame.pm will be better that it would have been had I not read these articles, when it finally does get completed. Henry S. Warren, Jr. (K1) rants about a fundamental problem, the best way to count set bits. Stunningly, divide-and-conquer approaches using bit shifting beat optimized brute force approaches, although calling them opaque is an understatement. Population count processing is applicable to a wide variety of basic data processing infrastructure problems. Warren's elucidation of the situation is a perfect example of the best practice development process: correct and fast, in that order. A USABILITY GURU: Ashish Gulhati (K0), who prefers to work remotely from the Himalayas, talks about how helping some social idealists inspired Cryptonite, his end-user-friendly encrypted webmail system, then launches into the history of the project, including architecture implementation details and discussion of security concerns and benchmarking, and how using well defined interfaces made replacing one component with a more efficient one with comparable functionality a relative breeze. Along with Lincoln Steins's chapter, this chapter is a nice introduction to object oriented Perl and how the reusability aspect of a good interface design effectively optimizes programmer time in any language. BIOINFORMATICIANS: Lincoln Stein (K0), without encumbering his narrative with O-O terminology, presents his Bio::Graphics system for displaying genetics research results as a example of usabilty done right, this time usability by one's fellow programmers. The advantage of using standard interfaces becomes apparent when it became possible to support many graphics formats by drop-in replacement of the GD library, which outputs in only one format, with a different library with the same interface but configurability to output in other formats too. The tension between perfection and deliverability is discussed, as Stein reveals his big wishlist item for his library but opines that the level of rewriting required is expected to prevent its reprioritization, especially as there is an effective workaround. Immediately following that, Jim Kent (K0) tells us how readability and understandability lead to extensibility in the Gene Sorter, including a short tutorial on writing polymorphic objects in C. MATH GEEKS: Adam Kolawa (K0) uses and endorses the CERN math library, which evolved into LAPACK. The well-commented core routines, in Fortran with bindings for use by other languages, are in regular use after three decades. Jack Dongarra and Piotr Luszczek (K0) discuss recent modifications made to LAPACK to take full advantage of modern hardware. KERNEL HACKERS:Greg Kroah-Hartman (K0) appreciates the discipline involved in maintaining the Linux kernel, where the acrobats operate in full view of the world without the benefit of nets such as dynamic type checking; Diomidis Spinellis (K0) uses the BSD virtual file system as the springboard for presenting general truths about indirection and maintainability; and Bryan Cantrill (K0) likens software bugs to sewage, in particular an embarrassingly unforseen race condition in a released version of Solaris. PYTHON MONGERS:* Andrew Kuchling (K0) discusses Python's hash tables, Travis E. Oliphant (K0) discusses the optimized n-dimensional iterator that lets the NumPy python math library do matrix operations without blowing its cache, and Rogerio Atem de Carvalho and Rafael Monnerat (K0) hype the flexibility of ERP5, an enterprise resource planning system that runs on python/zope. ROBERT HEINLEIN FANS: Ronald Mak (K0) uses J2EE beans to communicate both with Mars rovers and their legions of fans who want to download terabytes. PUTTING THE GOO IN GOOGLE: Jeffrey Dean and Sanjay Ghemawat (K0) discuss MapReduce. If you don't already know what MapReduce is, you probably know what to do to find out. THE NETWORK IS THE COMPUTER: Simon Peyton Jones (K0) introduces STM (Software Transactional Memory) which is an allegedly fool-proof replacement for locking discipline in multithreaded Haskell, and then discusses his solution to Trono's "Santa Claus problem" without explaining why the problem is supposed to be difficult. William R. Otte and Douglas C. Schmidt (K0) manage to abstract concurrency models out of their framework for networked services. Andrew Patzer (K0) reveals some practical best practices as he tells the story of doing a straightfoward piece of systems integration using RESTful web services. RADICAL USABILITY Andreas Zeller (K0), apparently a devotee of the Einsteinian craft-a-tool-to-straighten-the-bent-paperclip-from-the-good-paperclip-you-have-found methodology, uses an automated divide-and-conquer approach to discovering which of several thousand patches in the delta between two versions of gdb was responsible for a mysterious loss of function in the ddd graphical front end. Had ddd a debugging mode that logged the full interaction between itself and gdb, the world might not be the better for his automated technique. * Yukihiro Matsumoto (K0), the author of Ruby, might be annoyed that his essay on the nature of elegance, including the DRY (Don't Repeat Yourself) principle and other similarly useful tips, was not selected as a forward instead of buried towards the end of the collection. COMPUTER ACCESS FOR ALL: * T. V. Raman (K0) shares his amazement at how straightforwardly the extensible design of emacs Lisp, with its advice system that allows insertion of function before, after, or fully replacing any of the existing emacs functions, allowed his system to adapt emacs for eyes-free use to bush out over the extended development of emacspeak as a hobby project. Takeaways include the advice that when adapting a communication for another medium, it is important to communicate the message, not the artifacts of the previous medium. He is justifiably proud of his eyes-free calendar widget, among others. Bizarrely, there is no mention of Morse Code in Arun Mehta(K0)'s retrospective on a project to develop an improved system for the use of Stephen Hawking, who could only use one button (but he could control how long he pressed it, and could watch a screen as he did so.) BEAUTIFUL CAN MEAN EASY ON THE EYES: Laura Wingerd and Christopher Seiwald (K0), from perforce, discuss readable layout, including selection of line break points, and reveal the strong correlation between bugs and nested ifs. (Takeaway: prefer case statements, even if it means repeating yourself) CASTLES MADE OF SAND Brian Hayes (K0) demonstrates the truth to the saying "while in other disciplines the researchers stand on the shoulders of giants, in computer science we stand on each other's shoes" as he flails around in search of, and eventually finds, the easy way to find co-linearity of three points in order to analyze satellite photos of the lower Mississippi river, which tends to change course during high water. IN CONCLUSION I think if I had been asked to write a chapter for this book, I would talk about normalized Huffman tables, as discussed in Managing Gigabytes, which Hans Reiser recommended in response to my relating to him a conversation about ReiserFS had by the Kansas City LUG. Beautiful code has a lot of different things happening in it, with snippets of source code in various languages,\and nice diagrams where appropriate. It was not a fast read, although some of the pieces do flow nicely, due to the necessity of retooling one's entire brain from one essay to the next. Were I still a single nerd, and my girlfriend were to present me with Beautiful Code, perhaps as a birthday present, I would not hesitate to select her as my personal and permanent nerdess, all other things being equal. David Nicol, inventor of the online tip jar and always looking for collaborators with spare tuits, can be contacted through the comment form at tipjar.com. -- non-smoker since 11:31 pm october 10, 2007 "To do good in secret, and shun the world's applause, is the surest testimony of a virtuous heart and self-approving conscience." -- John Polidori ( http://tinyurl.com/ytm8ba )

1 0

playing video from a Server2k3 share
by Michael Haworth 11 Oct '07

11 Oct '07

Alright, I have tried this by myself for three nights now, and I am tapped out. I am running Ubuntu 7.04 on a machine that I am going to be hooking up to my entertainment center (to replace the media center computer that is full of endless blue-screens). At this point, the only thing holding this back is that I can't get mplayer (or VLC, totem, etc.) to play the video from the share (on a server 2k3 machine), they return an error that there is 'no input plugin to handle the location of this movie' - totally stumped. Here are the steps that I have tried so far. (server side) Start -> All Programs -> Administrative Tools -> Domain Controller Security Policy, then went to Local Policies: Security Options, and changed: * Microsoft Network Server: Digitally sign communications (always): DISABLED * Microsoft Network Server: Digitally sign communications (if client agrees): ENABLED * Microsoft Network Client: Digitally sign communications (always): DISABLED * Microsoft Network Client: Digitally sign communications (if server agrees): ENABLED * Domain Member: Digitally encrypt or sign secure data channel (always): DISABLED * Domain Member: Digitally encrypt secure data channel (when possible): ENABLED * Domain Member: Digitally sign secure data channel (when possible): ENABLED I have set appropriate permissions on the shares and the ntfs folders (client side) * Installed the codec packs from automatix * Installed smbfs & smbclient * Followed (or tried to) the directions at http://ubuntuforums.org/showthread.php?t=280473&highlight=mounting+smb+share s * Also mapped the drives through the 'Connect to Server' under Places If I copy a file to the local drive, it plays fine, so I know that I have the correct codecs and permissions, all I need to figure out is how to fix this last minor issue... Any help is appreciated Michael

3 2

Re: Kclug Digest, Vol 39, Issue 9
by cragos＠gmail.com 11 Oct '07

11 Oct '07

> Date: Sun, 07 Oct 2007 14:27:06 -0500 > From: leenix <leenix(a)kc.rr.com> > Subject: FOSS Solutions > 1. I agree with the philosophy behind FOSS > 2. There are a plethora of plug-ins developed to help extend our > infrastructure for our current (and future) needs > 3. If we find that a piece of software we downloaded (or purchased) > is broken, or doesn't do what we need it to do, we have the > source code and (hopefully) the resources to fix/change it. > 4. Not only are there several (competing) options for paid support, > there are a ton of free message boards, mailing lists and IRC > channels to get assistance from, making our virtual knowledge > bank HUGE > 5. Total cost of ownership is going to be a fraction of that of > closed source products. > 6. When needed, we can find closed source software to do what we > need when we can't find a FOSS solution 7. Vendor lock in - Ensures greater access to the developers themselves as support contacts, if the need arises. Ensures that meaningful third party support will be available for mainstream products if abandoned or obsolesced by their original authors. 8: Tendencies towards standards compliance and openness in the FOSS community make it far more likely that related projects will be able to effectively and efficiently interact. 9: Simplifies license compliance - Closed-source shops have the added overhead of needing to account for licenses to proprietary products, the hassle and man-hours involved in paying license fees, etc. Applications for the operating systems used in these shops, be they Mac or Windows shops, are far more likely to be proprietary shareware or purchased software, adding to the transaction costs for adding new software. 10: (More a plus for *NIX than FOSS) Having more mature command line interfaces than are available in pre-Win2k7 builds of Windows Server substantially cut the amount of time needed to populate changes across multiple servers. Even after the adoption of the yet-to-be-market-tested server operating systems that ship with PowerShell, the size and maturity of the body of available code and documentation for shells used in UNIX and Linux administration will continue to vastly outweigh that available for Windows for some time. Note that O'Reilly books on the relatively young Bash shell have been through several revisions already. That might help, Sean Crago

11 16

Intentional reversions of rights clauses for "abandonware" right of authors.
by Oren Beck 11 Oct '07

11 Oct '07

Ok folks, here is a potential answer to the issue of "abandonware" . Possibly even a poison pill to the "buy a project to bury it" megacorp game too. I freely admit to not being the most polished proponent for a concept, but sincerity counts too I hope. Le me raise an initial question. Can you think of an IP work that was rendered "dead" to us by abandonment of some sort? The kernel of this concept is to keep code from being buried by abandonment either intentional or otherwise. It was repeated many times in earlier discussions on our list that a creator/author/coder has certain rights to their work .Author's rights are assignable, even possibly with event clauses according to some precedents in EULA law . That last one in my first application being that if one clause is held invalid all others NOT so invalided remain in force. SO, as some of us are coders and authors or other "content creators" what of a concept where: If we assign rights to one of our works to external parties they have to "use it or lose it"so to speak. Publish us or give our rights back! Have our works in use and circulation or we get them back Or at our option set them free as opposed to letting them be buried alive. This for example would not have stopped MS from buying Hotmail, but potentially COULD have returned the original; CODE of the project to the FOSS community! Same with some of the projects that were under earlier discussion. A megacorp CAN still decide to wantonly abandon a project, but the CODE needs a way of not being denied "life" Possibly a tagline conveying a "release date" for a work" addendum to CC type contracts? EX: The work that is known as "FooBlank" will be released on 30 Feb 2008. Constructive comments folks? "The code we create deserves a chance to be obtainable" "

2 1

RE: Kclug Digest, Vol 39, Issue 9
by lerninlinux＠comcast.net 10 Oct '07

10 Oct '07

-------------- Original message ---------------------- From: "Phil Thayer" <phil.thayer(a)vitalsite.com> > > > > > Ah yes, phone support. > > > > "Ok, now hit 'Enter'." > > > > "Ok" Clack. Clackity clackity clackity clackityclack > > > > "Wait, what did you just do?" > > I had a guy that the technician had set his password to blank. Then > about three months later he called support and said he couldn't remember > his password. (Apparently he had never shutdown his computer and there > was a power outage that shut it down for him.) After trying a number of > standard passwords I told him to enter a blank password. His response > was "Is that case sensitive?" Uhhhhh??? Yes? No? Just press the > "enter" key without entering anything. It logged him in! Scary part > was, he was an instructor at a college... > _______________________________________________ > Kclug mailing list > Kclug(a)kclug.org > http://kclug.org/mailman/listinfo/kclug Sounds like the one I knew that taught at a local, laughed at school. Somebody gave him my number (could have only been a couple of people, who didn't own up to it). He needed me to make room on his pc, so he could install some program (don't remember what it was now), and use another program that you would laugh at. He thought he could just delete the programs in office or windows that he didn't need. His hard drive had tons of space on it, and he asked how to install this program, that had Disc 1, disc 2, disc 3, LOL. The ONLY program he could run, was the one that he taught and used. He ended up buying the video professor series, to learn how to use his pc. I heard more about that school, that I stayed FAR away.

1 0

Response to the devil's advocate
by cragos＠gmail.com 09 Oct '07

09 Oct '07

>1. I realize the source is available, but I want my developers >developing OUR software not OS (Fill in your other FOSS software here) >software. Not relevant. The developers may alter open source code, but they may not alter the code received from the proprietary vendor, in most cases. Assuming your developers will develop the same breed of software in FOSS land as they would in proprietary systems, this statement has no bearing on the discussion whatsoever. More importantly, in the open source community there are more freely licensed libraries than are available in from proprietary vendors, and the same code and libraries are available for Windows as well. Competent developers that stick with LGPL licensed libraries and with more basic tools such as those commonly available for PHP and perl will have no issues whatsoever, given the most basic level of awareness of how to work with these licenses. The statement above seems to imply more a fear that your developers are incompetent and will plagiarize code incompatible with your company's desired license than it does anything else. Again, the same code is available for Windows as well, and would be equally applicable if you were working with something like Windows CE. This point is not all that terribly strong. 2. If I buy a piece of software that is closed-source, the company selling it to me has to support it. If something is wrong with it, they'll fix it, because that's where they make their money. This point is, but there's a major trade-off. You must choose between being locked in and supported by the author company or having free choice of several large firms that are each similarly well suited to remedy your problem. The major commercial distributions support developers that at the very least package and closely monitor and, at the other end of the spectrum, actively develop all the major packages in the operating system. If something goes wrong that can't be fixed without a software change, this means you're actually far more likely to be able to find the fix in the FOSS environment, due to third parties having greater access to the code and greater familiarity with the code. An argument can be made ( http://msuspartnerblogs.com/blogs/nealw/archive/2007/03/25/7708.aspx ) that Microsoft patches their code more quickly than Red Hat, Microsoft routinely has far more severe security holes to patch. Equally important, if you are aware of a bug that is affecting YOUR systems, it is far simpler to use your clout with an open source vendor to get the problem fixed than trying to steer the monopolist, for all the same reasons one could not hope to move Ma Bell, and one can only rarely hope to push Apple because they are run by space aliens. In the open source community, the numbers of third parties that are capable of fixing an application, library, etc that is broken in a way that effects you makes it far simpler and, if needed, far quicker than dealing with a closed source vendor. Furthermore, when dealing with applications, Microsoft might sell SQL and HTTP servers, but they aren't going to sell you your entire application stack, unless you're in a mind bogglingly boring company. A Linux distribution is, and will support it in its entirety. 3. If I buy [closed-source company]'s software I know it will work with their Database, Mail server, Office Suite, etc. because it is made by the same company. I'm not sure that we'll be able to get [open-source company]'s software to talk to our existing infrastructure, our to our partner's existing infrastructure. As stated above, yeah - Microsoft's Office is going to integrate with Exchange effectively, for the most part, and it is far more stable and mature than it was. Previous builds that I've seen were enough to drive me nuts, and I'm still far more comfortable and capable dealing with a Maildir mail store than their proprietary ones, but I can see the benefits. But again, those three applications and the OS are not all you're buying. Red Hat, SuSE, Ubuntu et al will actively support most every application and library that they ship. While they are the initial authors of little, they, again, are the authors of parts of most of the applications that they ship. They offer support for a broad, overarching range of applications and libraries that makes Microsoft pale in comparison, and, if you're displeased with their take on an issue, you can take your specific issue to another company with far greater ease. On the infrastructure point, however, you're making a permanent choice if you're going with a vendor that's going to lock you in to unpublished proprietary protocols to do something as mundane as mail transfer. Only one part of MS Office integrates in any meaningful way with Exchange - Outlook. Unfortunately, their ancient webmail application bundled with Exchange is still a crufty POS, and I'm not referring to points of sale. In Linux, you have many, many other options, but, if you want a full groupware suite, there only appear to be three or four that matter, counting the proprietary, cross-platform Lotus Notes. Each ships with a mail client just as tightly integrated with their server solution as Outlook and at least one shares developers and tight integration with Evolution. More importantly, the vast majority of these systems use open standards to perform the shared calendar tasks, to push and store their emails, etc. This means that you have far more choice.... or rather, you have SOME choice, unlike with the Microsoft groupware server, which is solely designed to work with Outlook. While Outlook may be slightly more refined than the others - I wouldn't know, I just use Thunderbird, and am aware that its scheduling system is still very much under development - it is just as important that that same choice also gives you many, many options for a webmail system that doesn't suck. Fancy AJAX mail clients that perform on par with Gmail are available for free or a pittance, and other mature mail systems that are far more user friendly. Full PHP groupware suites such as the Horde also exist, although I would not recommend them at present - seen our install compromised one two many times. More mature and stable mail systems such as iloha and Squirrelmail also exist, and suck much less than the one shipped with Exchange. The question you have to ask yourself, on a case by case basis, is does X proprietary vendor offer features L, M, & N that are so beneficial that they outweigh the benefits of: A: Having multiple available vendors that are able to support and, if need be, develop the application. B: Having vendors that are willing to support and, if need be, develop the application. (Ever tried to file a bug report with Microsoft? It isn't pretty - http://www.oreillynet.com/mac/blog/2002/06/mission_impossible_submitting.ht… ) C: Using published, open standards that will allow us to integrate products from other vendors and projects in the future, and allow us to develop our own related applications and systems in the future. D: Your personal experience and comfort levels with UNIX, which just happens to be FOSS. Retraining in the latest and greatest proprietary application costs an arm and a leg. It had better be worth it, if the boss is going to have to put you through that level of rigorous training or willing to pay the expense of training an already expensive new hire already familiar with that fledgling technology to work within your firm. -Sean

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

KCLUG