Nat Friedman talks of Ximian, Gnome, and Red Carpet

Nat Friedman often seems to live in the shadow of his famous coworker, Miguel de Icaza, but today it's his turn to shine. You asked Nat questions last week. This week he answers, in detail, with lots of links, touching on subjects ranging from Gnome's future directions to how Microsoft is dealing with Linux as a competitor to Windows.

1) Exchange Like Product
by Kaypro

Currently the Exchange Connector seems to integrate quite well, are there any plans to create a standalone server with similar capabilities to Exchange Server?

Nat:

There are no plans today, but it's a really appealing idea.

Ximian's goal is to enable corporations to deploy and use open source-based desktops. One of the major barriers to this happening today is interoperability with the rest of the corporate computing environment. In the world we all inhabit, that means interoperability with Microsoft products.

When we were doing some product planning and market research early last year we found all these cases in big companies where people had to have two computers on their desk: a Unix machine for their real work -- development, CAD/CAM, 3d rendering, etc -- and a Windows machine so that they could speak all the protocols and file formats that the rest of the office speaks. And we were like: this just ain't right.

In many of these cases, when we asked people, they said that what was keeping that Windows machine on their desk was not, as we expected them to say in all cases, Word or Excel or Powerpoint, but it was actually in many cases Outlook. What happens is that the IT department will proclaim from on high that Exchange is the corporate scheduling standard, and if you ever want to coordinate a meeting or to schedule time in a room or with a projector or any other resource, you have to use Exchange, or you're simply out of the loop.

So this was a situation where providing this functionality under Linux eliminated the need for that Windows machine. This is a clear financial win for the customer and a clear win for the open source desktop. Basically, the Connector was a really obvious product to build.

Will we ever build a collaboration server of our own? It is something we've had some requests for before, and of course we're always listening to our customers and users, but we have no plans to build one today. Tell you what, if you would be interested in paying for such a thing, send email to [e-mail] and let us know. :-)

2) Microsoft and Mono?
by zoward

Have you gotten a sense of how Microsoft views the existence of an open source alternative to .NET? Do you think that, over the long term, Microsoft will grow to love, ignore or loathe (and perhaps seek to undermine) Mono?

Nat:

Open source software is a threat to Microsoft's business model, and it is a competitor which they cannot attack with their traditional maneuvers. At the same time, the events of the past seven years, especially the emergence of the web, Linux, Java and XML, have shown Microsoft the marketplace power of open standards. For these reasons, Microsoft's posture toward Mono and similar projects can be hard to gauge.

But the fact is, Linux and other open source efforts are a source of competition for Microsoft, and that is why they are investing 25 million dollars with Unisys to discredit Unix: they are once again facing competition, but this time there is a united front of users and companies around the globe that opposes them. Open source has given the world a common ground.

At the O'Reilly Developer Conference last year on a panel with Michael Tiemann, Tim O'Reilly, and others, Craig Mundie, Microsoft's CTO of Advanced Strategies and Policy, said (I am paraphrasing): "The thing Microsoft does not like about the GPL is that it creates a closed community." Yes, he actually said this, and while the entire audience sat stunned and struggling for oxygen, I remember Tim O'Reilly did not miss a beat, responding with "But so does Microsoft!"

Mono is an open source implementation of the C#, CLR and CLI cross-platform development framework that have been submitted to ECMA for standardization. We are implementing this framework because we believe it is important technology, and that the world should have a free, standards-compliant version of it.

Microsoft wants the ".NET platform" to be adopted, which is why they submitted it to ECMA. Whether or not Microsoft will change their minds, retract their submission, and decide that they do not like Mono is not something I can predict, but if they do, we are ready to adapt to the change and ensure that this technology is available to the world.

3) Core Gnome technologies
by wrinkledshirt

Despite its relatively short lifetime, Gnome's been really great about embracing all sorts of different technologies -- gtk, ORBit, bonobo and now Mono. However, it's sometimes difficult trying to figure out how this all ties together (if it's supposed to at all). Generally speaking, if someone's going to want to develop for Gnome in the future, how should they prepare themselves? What should they want to learn?

Nat:

Actually, the goal of the infrastructural work in GNOME is to abstract all of the underlying technologies away from you so that you can focus on writing your application. We want you to feel the joy of being able to sit down and easily build something, not to hand you a whole bunch of new stuff to learn.

Nowadays GNOME application development can be done rapidly and easily using Python or Perl and the Glade GUI construction tool.

For a lot of people, these languages and tools are the best way to build an application. The GtkPerl site has an example of a GNOME panel applet written in just 60 lines of Perl (and I'm sure it could be done in less). Not everyone knows that Anaconda, the Red Hat Linux installer is actually written using PyGtk.

Using Glade to create your user interfaces not only frees you from the arduous task of manually doing all of the widget creation and packing, it also makes your application more flexible because the GUI layout is loaded at run-time from an XML file. For the GNOME project this has been really helpful, since it means that a lot of UI design and prototyping work can be done without the need to even touch the code.

If you want to learn more, developer.gnome.org has a pretty good overview of the GNOME architecture.

All of the GNOME technologies that you've heard about work under the hood to provide consistency, configurability, and scripting features that you, as a programmer, only come into contact with if you need them. The goal, to steal directly from Larry Wall, is to make the easy things easy and the hard things possible.

For example, you might (or might not) have heard of Atk, Gail and at-spi. These are accessibility ("a11y") technologies that are in GNOME 2 to make it possible for applications to be used by people with various kinds of impairments. But you do not need to be exposed to any of the details of CORBA in order to use them, and in fact, some of the a11y features come for free just from building your application using GNOME 2.

By the way, I happen to think that accessibility is a killer feature in GNOME 2. At GUAD3C, Marc Mulcahy gave a great demo of how a sightless person can navigate the desktop using a screen reader. And we have been working on a set of accessible icons for GNOME 2 as well. There are cool side effects too: Because GNOME's accessibility infrastructure is done programmatically and at the widget level, you can actually attach to a remote running application and introspect and act on its widget tree. This may make it possible for us to eventually have a very high-quality automated UI testing tool.

Check out the GNOME Accessibility Project web page for more information.

As for Mono, it is still a technology under development, and the GNOME project has not made a decision to adopt it in any way yet. Work on C# bindings for Gtk is progressing, however, so you will be able to write Gtk and, eventually, GNOME applications in C#.

4) Usability research
by nakhla

One of the big problems facing GNOME and other open-source software is that of ease-of-use. Microsoft and Apple spend millions of dollars when developing new operating systems or UIs in order to ensure that their product is easy to use for the non-geek end user. What kind of useability studies has Ximian conducted? What is Ximian doing to correct any problems that the research has brought to light?

Nat:

Ximian and the GNOME project have learned from standard, existing industry practices for building usable software. In short this means designing for usability, performing formal usability testing on real users, and treating usability problems as first-class bugs.

The GNOME Usability Project is a nice central resource for a lot of the usability work that has gone into GNOME. Recently the project has been making a lot of progress on the GNOME Human Interface Guidelines, a set of UI rules that will help GNOME achieve much better consistency in its user interfaces. The results of the comprehensive GNOME desktop usability study that Sun performed last year are worth a read, too, even if we've already overcome a lot of that stuff in GNOME 2.

In the course of the design of Evolution 1.0 and 1.2 (due out this summer), Anna Dirks, our UI designer, performed many dozens of usability tests on various parts of Evolution, using a wide variety of people with varying degrees and types of experience using computers. Anna delivered a nice talk on the usability testing process at the GUADEC Conference

An application's usability is directly related to the ease with which a user can predict its behavior when he gives it input. This is why usability testing is a productive activity. In its basic form, it goes like this:

1. Create a prototype of the interface you are designing. In some cases prototypes are created using "scripting" languages or "RAD" tools, and sometimes they are just printed onto "paper." This last type is called a "paper prototype," the name deriving from the "paper" on which it is printed, and the fact that it is a prototype.

2. Coerce an appropriately representative set of individuals into participating in the usability test. The use of lethal force may be necessary.

3. Ask the user to perform a certain task, using the prototype.

4. Observe and record the steps the user takes, with particular attention to his mistakes.

5. Rinse, lather, repeat.

The fundamental premise of the usability test is that the user has certain expectations of how a given interface will behave, and the thing that a designer must do is to identify the places where his interface does not conform to those expectations, and to fix them.

At Ximian we've gotten subjects for our usability tests from a variety of places; there's a movie theater downstairs from our office and sometimes we'll hang out there and offer people free movie passes to participate in usability tests. So we get a pretty broad audience.

All usability issues that arise during a usability test are filed as bugs in bugzilla alongside other issues, and of course the subject's comments inform the revised design of the interface in question.

For GNOME 2, we decided to revamp all of the GNOME stock icons to improve their consistency, usability and to brighten up the style a bit. Ximian has contributed all of these new icons back to GNOME; you can check them out on developer.ximian.com.

Havoc recently wrote a nice piece which covers UI design in free software, and in GNOME in particular.

5) Conflict of Philosophies
by polyphemus-blinder

I would like to know:

What is your take on the apparent paradox resulting from:

1. the goal of uniformity on the Linux desktop, and

2. the many, many, groups who have this as their own special goal?

Mandrake and RedHat work toward this on the OS level, and Gnome and KDE battle it out on the desktop integration level, and many others espouse some sort of a "grand unification theory" of Linux.

Do you subscribe to the theory that less is more, or that multiple groups with a common goal will result in the goal's earlier acheivement?

Nat:

In any large-scale human endeavor, consistency is a very difficult goal. I once heard a senior Microsoft project manager express the goal of consistency in software thusly: "A program should look as if it were written by one person." This is a thing that everyone struggles with.

To give you a short summary of my answer:

(1) Consistency is hard.

(2) Decentralization and parallel development are inherent to open source software.

(3) Open standards and making an effort to work together are key. Let's try to do more of that.

Consistency in software applications means fewer surprises, a gentler learning curve, and being able to get your work done without tripping over an application's special quirks along the way. This is especially true of the interfaces that the application exposes.

For human interfaces, consistency means that the elements of the application do what the user expects them to do, and that the interface, consequently, does not get in the user's way. This means that a dialog's Close button is always in the same place, the menubar always appears at the top of the window, and Ctrl-Q always quits. Usability flows predictability which flows from consistency.

For programming interfaces, or APIs, consistency means that the methods you invoke have predictable characteristics: similar naming, the same memory management semantics, the same return values in an error condition. This means cleaner code, less time spent hunting through documentation, and fewer bugs.

So we can agree that consistency is a good thing. Two things are needed to achieve it: a standard, and a way to enforce that standard.

In more centralized environments, such as companies, these things are easier to do. It is naive to think that any company, even Microsoft is fully centrally controlled, but it is certainly much easier to enforce a single standard on people when you are paying them, and when you have editorial control over the final product.

But even with a single, documented standard and even if you are paying people's salaries, consistency does not come easily, even in the most centralized environments. At one point Microsoft had at least nine separate internal implementations of SOAP, and only recently have these all been consolidated...into four.

So how on earth do we achieve consistency in a decentralized environment? Given that starting your very own open source "project" is a matter of a few clicks on sourceforge, how do we "prevent" people from creating applications that do not adhere to some common set of ideas as to how they should behave? Given that there is no central control of what happens in the open source desktop world, how can we even create a standard that we all agree on?

I remember when Mac OS X first came out, people asked a lot of similar questions: How can we ever create an interface that is as consistent as this in our weirdo free code, free love, gift economy, bazaar-inspired noospheric environment?

This question can be considered at different scales: how can consistency be achieved within a single project, and how can it be achieved in the open source world in general.

And this issue of decentralized development comes up in other guises as well. In addition to bemoaning a lack of consistency, people talk about duplication of effort and fragmentation. They say things like: "If only we could focus all of the energy that has gone into producing all of the IRC clients in the world on building just one IRC client, think how awesome it could be!" People really say this sort of thing. I have heard them.

And, of course, there are those in the press and on the mailing lists who see this very same pattern in what they call the "GNOME vs KDE wars" or "the desktop wars." This is the "How many Linux distributions can you count?" conundrum.

Many people who are much smarter and better looking than I have responded to this question at various times.

Linus has said that he believes that in the Linux development community today, there is a "psychological barrier to fragmentation," and that this barrier is the learned result of the Unix wars of the 1980s.

Alan Cox has said that implementation fragmentation is not important, as long as care is taken not to break interface compatibility. The important thing, quoth Alan, is the existence and adherence to open standards. And Eric Raymond has pontificated at length about how it is the nature of the open source community, when confronted with a problem to solve, to try "all solutions at the same time." That is, I think Eric would tell you, the nature of the open source world, and, in many ways, its greatest strength. And of course, Eric is right. Seriously, I love that guy.

If on an iron-gray fall day you have looked up and seen a dark spot moving against the sky and changing shape and size but still moving smoothly in one direction and then it came closer and when you looked you could see the individual birds flapping their wings and shifting forward and back in the formation and alternately turning against and away from each other but still somehow moving all together as one mass, I think you have seen something that resembles the greater open source development community, if there can be said to be such a thing.

The thing that the birds are doing is called "flocking," and today the problem of flocking is still an interesting issue in algorithmic circles. The basic scenario is that, with each element in the flock making its own individual movement decisions based on its own individual and unique sensory input of what is happening immediately around it, the flock must somehow move along a single path, as a whole. The analogy of the Boids flocking algorithm actually runs deeper than you might expect; check it out sometime.

What is important in open source software is doing the actual human work of getting people together and creating the open standards that will allow us to function as a group, and to move in the same direction. And the way to do that is through open, shared standards.

I'm not talking about a kind of abstract standards process where an aesthete group of monks argues for centuries in the thin mountain air about file system standards before descending with etched tablets, but a process where implementors agree on good-enough standards of existing practices in the places that matter, today. Standardization is a way for us to align our directions, maintain implementation distance, and follow a common flight path, not an end in and of itself.

The thing to recognize is that the problem of creating a consistent desktop experience and the fact that our approach is a multi-pronged, decentralized, evolutionary one do not have to be at odds with each other. The key to consistency is to work toward it.

6) As a business
by Fizzlewhiff

Is it frustrating to see potential revenue lost due to offering the same products for free? Do you ever run the numbers to see what your income potential might be if you stopped giving away the same software you sell or do you believe that the Linux community, as a whole, cannot and will not support companies who only sell Linux software?

Nat:

If in the last two years we hadn't put out approaching 2 million lines of GPL'd and LGPL'd code, we would not have nearly the success that we have today.

If you're going to run those kinds of numbers, you should also calculate:

1. How much extra would you have to spend on development in order to compensate for the fact that you will no longer have the help of a large community of testers, translators and hackers?

2. How much do you have to spend on marketing to even reach the same level of name recognition you can achieve by being a responsible, active open source software development company? Would you have the same amount of credibility?

During the several months that preceded Evolution 1.0, we averaged around 10,000 daily downloads of the Evolution snapshots, and many of the downloaders were actively reporting and fixing the bugs that they found. How much would it have cost us to manually test Evolution against the wide variety of IMAP, LDAP and Palm devices that the Evolution codebase was exposed to by this army of users?

This kind of thinking may sound cold and not particularly ideological, but if you're going to perform one kind of calculation, you gotta do them all. I have actually heard of open source companies sitting down and working out the second, marketing calculation, and including it in their business plans as a rationale for writing free code.

7) Co-existance of Red-Carpet and up2date/RHN
by yusufg

Hi, Red-Carpet seems to offer functionality similar to up2date/redhat network. However, there seems to be a very substantial lag between packages made available via Ximian's redhat channel and up2date.

An example being (till now, RPM 4.0.4) is not available via the Redhat 7.2 channel. Is Ximian going to ever make a policy statement as to what is the maximum duration their userbase will be diverged from receiving the latest updates of their respective distributions.

If there are specific packages which are likely not to be made available via red-carpet, can their be an official statement on this so that users are aware of the pros/cons of using multiple update mechanisms?

Nat:

Our policy is that all distribution and third-party updates are made available through Red Carpet as soon as they can reasonably be pushed without breaking other software for the user.

For example, with security updates, these are always made available as soon possible, often within just a few hours, always within a day.

With something like the RPM 4.0.4 update, however, sometimes we have to lag behind the upstream provider, in order to ensure compatibility. This does not mean that we hate Red Hat or that we do not care about users, or that we are lazy.

In the particular case of RPM, new releases of RPM often break binary or database compatibility with old versions (this was true with 4.0.4), and so we are cautious about making these available to users until we have first ensured that Red Carpet will continue to work on your system. I am not trying to pass the buck to Red Hat here. They are great people. Our userbase, in running Red Carpet, just happens to have a different set of needs than Red Hat's, and this is what, in the case of RPM 4.0.4, created the delay you noticed.

To answer your second question, as long as the packages that are shipped by the upstream providers are open source, and as long as we can legally redistribute them, we will make them available via Red Carpet.

8) Lack of documentation for GNOME internals
by Tet

Are there any plans to increase the amount of documentation on GNOME internals? While GNOME seems to have plenty of trivial documentation (such as the GNOME User's Guide [redhat.com], there's virtually nothing that explains what's going on underneath. Are there any plans for a "GNOME Administrator's Guide"? I'm thinking of something that documents usage of files in $HOME/.gnome, what session management is and how it works, what controls the contents of the GNOME menu, and so on. For example, when GNOME fails to correctly save session information, I'd like to be able to check the documentation to see what should be being written to .gnome/session. At the moment, I just have to guess. Some of it is reasonably obvious from context, but it's the sort of thing that really needs formally documenting.

Nat:

So, for a lot of the stuff you're talking about, the documentation is out there. If you want to learn about the session manager and how to configure it, check out the man pages for "gnome-session" "default.session" and "save-session". There's also a white paper covering a lot of the configuration files, though it is out of date. Collecting and updating all of these things into a single "GNOME System Administrator's Guide" sounds like a great idea for a project for someone :-).

The GNOME Documentation Project and the individual efforts of developers and users have produced a large amount of documentation to date. In addition to the GNOME User's Guide that you mention, there is the user's manual work that Sun has been doing. There is also a lot of developer documentation on developer.gnome.org, including some useful tutorials and white papers.

With all of the large vendors that are shipping GNOME on their workstations, I think it's a safe bet that the components of an administrator's guide will come together in the near future. I know that, inside Ximian, we have recently written for a customer some documentation specifically focused on issues that would be interesting to system administrators, and naturally we will be working to release this to the community at some point soon.

Of course, if you or anyone else out there wants to join up with the GNOME Docs team and start assembling such a guide, you would be welcomed with open arms :-). If you don't have time to do that, you can contribute by filing bugs in bugzilla.gnome.org whenever you find problems or missing pieces and by contributing fixes to the individual projects. Check out the gnome-doc-list mailing list for more information on how you can help.

9) Why subscribe?
by JThaddeus

I was considering subscribing in order to improve the performance of downloads (which have gone to a snail's pace since the subscription program began) but two out of three of my last update attempts have ended in file not found errors. This type of error doesn't give me confidence in how well RedCarpet setups are tested. So why shouldn't I just forget about subscriptions and go with KDE?

Nat:

Without more information, I can't say exactly what the problem is that you were experiencing. That type of issue can sometimes happen if you're updating from one of our mirrors that is in the process of syncing from our master site.

I can tell you that we do directed testing on all updates that are pushed to Red Carpet, on every single supported platform, before an update is released. Additionally, we pay close attention to the bug reports that our users file in our bug tracking system, and make an effort to address all of those as quickly as possible.

Just last week we released a new channel in Red Carpet called "Untested," which contains the pre-QA versions of all of our Ximian GNOME updates before they hit the main channel. Similar to the Mandrake Cooker or Debian unstable, this is a way for the update junkies of the world to get an early glimpse at new packages and versions before they hit the official channel. And of course, this is a way for us to get broader user testing and resolve problems earlier.

Also, by the way, the bandwidth we've allocated to our free public Red Carpet servers has been steadily increasing since the launch of the subscription program. If the servers have gotten slower, it's because the user demand keeps increasing.

But whatever your experiences with Red Carpet, they should not be brought to bear on your choice of desktop. Red Carpet is a software management service that is independent of your choice of desktop or web browser or editor or whatever. And because the Red Carpet client is statically linked, you don't even have to have GNOME installed to use it. In fact, about 20% of Red Carpet usage is by people who want to get updates to the packages provided by their distribution, not Ximian GNOME.

10) External Compatibility
by dspeyer

What plans do you have to improve compatibility with the non-GNOME world?

For example, do you think it's practical to implement Xaw as a front-end to GTK? That would get OpenOffice integration real fast, among others. What about a unified theme format with KDE? Or a common protocol for copy/paste?

It seems like this sort of stuff would be really helpful -- what's actually in the works?

Nat:

Compatibility actually has less to do with an application's choice of drawing toolkit than you might think. Of course, there's nothing to prevent you from running a non-GTK application in GNOME, and it's not necessarily the case that the user experience is hugely degraded if you do. I know of a lot of KDE users who started using Evolution in the last couple of months, because the functionality is so rich, which is great.

GNOME and KDE have had drag-n-drop and cut-n-paste interoperability for quite a while, and we also use the same .desktop file format to store launchers and menu items. You can track a lot of this stuff at freedesktop.org.

Open Office does not use Xaw. That being said, it would be great if OpenOffice used the Gtk drawing primitives so that OpenOffice would be theme-compatible with GNOME. It would not be a total integration, and the behaviour might still be different, but it would help the desktop to look more like a single unit. In fact, it would be possible to get Qt to use Gdk as well, which could make shared themes possible there too.

Another step would be to adopt a common set of icons; baby steps like this can improve visual harmony a lot, even if the "compatibility" is only at a very superficial level. These first steps could be followed by deeper integration, like a working bridge between Bonobo and Uno, the OpenOffice component system.

A unified theme format with KDE would probably be difficult, having a theme or set of core themes for GNOME and KDE which looked and felt the same on both would be a nice step toward making the desktops more compatible to the user. There have been noises made recently that this kind of thing is a possibility, and Ximian would be fully supportive of that.

Though these surface integration steps would be nice, the area where inter-project compatibility is most badly needed is configuration. If someone is running a mixture of GNOME and KDE applications, Mozilla, OpenOffice, and older Xtk-based programs, they need to be able to make configuration changes that are reflected in every application. Having to go to N different places to set your default URL handler, theme, or MIME type bindings is a real usability problem. Jim Gettys talked about this a lot at the most recent GUADEC. Keith Packard's recent fontconfig work is an excellent example of this.

Unansered Question

[huckda]

oh...I wanted to ask him...
Why the monkey?
Why not a Rhino?
or Hippo?
How come everyone picks little animals for their logos? I wanna see a duck-billed platapus as a logo!

Re:Unansered Question

[sar]

the 4 cd set from walnut creek of slackware '96 had a duckbilled platypus on it. If i had a scanner I'd scan the cover so you could see.

Re:Unansered Question

[Soko]

I wanna see a duck-billed platapus as a logo!


OK. Here ya go. [sourceforge.net]

Soko

Open Source Exchange

[stevey]

I've been thinking of an open source exchange for the past couple of years. Right now I have access to an exchange + outlook environment where I can play with things.

As my current project [gnump3d.org] is almost feature complete, (and well tested), I'm seriously taken with the idea of starting work on this.

However I have my reservations also: its a huge job for an individual to take on singlehandedly - and having lots of people jump in before any code is reached can lead to a terrible time where nobody agrees + things decend into lots of aimless discussion. I've always though the best open source projects are the ones started by a single individual, which has been released - then incrementally improved upon by others; here I'm thinking of the "biggies" like Apache, The Kernel itself, Samba, and Squid.

The way I see it it would be a lot of work getting a compatible stand-alone calander server working, then there'd be the simplish job of integrating that with an existing open source, assuming I'm not missing anything, right?

If anybody has any serious thoughs on this I'd love to hear them - either here, or via mail...

(OT: Why is it that Squid always seems to be neglected when people are talking about stable, successfull open source projects - Squid rocks!).

Squid & Samba - was Re:Open Source Exchange

[Malc]

Yes, Squid is excellent. My ISP uses it as an optional proxy. I rarely have problems with it, and as a bonus, they have it configured to block web ads.

As for Samba, I've actually been very disappointed with it in the last few days. I'm wanting to set up a NT domain at home, but Samba 2.2.3 doesn't seem to support inter-domain trust relationships, making it completely useless to me. NT4's life cycle is approaching its end, so I guess Samba isn't all it's been advocated to be.

[OT] GNUMP3

[AirLace]

I thought the mp3 format couldn't be used by official GNU projects because of the patent issues. Surely it should be GNU Ogg Vorbis or something? Besides which, isn't the name a bit ambiguous? It sounds like a clean-room GNU implementation of the MP3 codec or something.

Re:Open Source Exchange

[Telastyn]

One thing that I've thought about, and is *ugly* albeit workable, is having a plugin/attachment to outlook so it can access "proper" calendaring. It's not terribly hard I recently found to write a script to enter and retrieve calendar information in outlook, using outlook's dll's.

It's a simple COM interface, which can even be accessed by PHP (which I used, because VB sucks (imo) and c*'s string parsing is painful). Why not just attach an IM style (or better yet, a real fekking IM) mini-server to the php script? Normal calendar invites go out via email, get grabbed by the mail server, and sent via the IM (or the protocol used) to the little mini-server. Have a mechanism to accept the invite, and the php script enters the invite into the user's calendar, or a central open-format database where other clients can see info.

(note: php cal access source available on request, just reply)

IMO the best way to break Exchange in the office is by including calendaring into a corporate IM service. It must be done quickly, as MS isn't dumb, and Exchange 2000 includes IM, though almost nobody uses it!

Re:Open Source Exchange

[stevey]

One thing that I've thought about, and is *ugly* albeit workable

Its an interesting idea - which would be fairly simple to setup.

If this were all client side, though, wouldn't the copy of Outlook still require the use of an Exchange server?

If it did then there'd not be much justification for making the switch - as presumably people would be happy with it. If there was no need to use Exchange it would be cool though, it would just require the installation of a simple server somewhere and the COM control on each client.

(I should look to see what happens when you setup Outlook to be in the non-corporate mode - I assume that the shared stuff just disappears?)

Re:Open Source Exchange

[Telastyn]

In Outlook XP at least, there is no longer a "corporate" mode, Exchange is just one more option. (meaning you can use exchange and imap at the same time (wow)).

From what I understand you can still send calendar requests using the 'local' calendar, you just cannot see when other people are scheduled (which is why you have a web browser or something that can view the centralized DB you have elsewhere).

You'd need to schedule something to run every so often to check if the user modifies/deletes something (or write a proper com addin) so that Outlook and the server are synchronized, but the idea is more that Outlook functionality would be ancillary to the full functionality of the program.

The full functionality would exist in something you had control over, like a cli client, or a web front end (though web front ends are bad, ugly, and limited), or through an IM. There are many community run IM clients (Trillian!) that could probably very easily add functionality for this.

IMO the IM tie in is logical because (to me) the protocols to do both are very similar, and to a degree help solve quick communication problems.

Anyways, I ramble... The reason I originally looked into the 'solution' isn't so much to get windows users off of outlook (which would be nice, but imo, impossible) but to get everyone else into scheduling, and get control of the server. Plus it is something simple, for I am no great coder.

Re:Open Source Exchange

[ahde]

invitations could be handled by adding a few parsing rules to something like a majordomo style mailing list server. You could even send an XML format like the outlook text+html .eml (or whatever it is) mime type and build a handler for outlook (or other clients) to have a button that says "accept" instead of reply" -- and someone using pine can just type "accept" in the subject line and have full productivity integration. Jabber or even Biff could do pop-up reminders.

There's a project called PHP groupware that I haven't really looked at, and I think they're teaming up with GNUe, but I'm pretty sure they have the bulk of what you want. Of course, free software is all about building it yourself and then stealing from the competition when you get stumped.

Let me know when you're ready for help. I'm looking for a project to join. I was looking at GNUe, but don't think I'm cut out for "business" applications. Besides, I don't know python.
Its more fun to get in at the ground floor anyway.

I've been toying with my own EJB-like project for semi-persistent object caching for cgi & php, but I was stalled on building (well, designing) a pipeline similar to servlet forwarding. Now with Apache 2.0, that won't be a problem.

Squid rocks -- was Re:Open Source Exchange

[bluelip]

I believe it is because people don't notice somthing unless there are problems with it. With squid, you can 'set it & forget it'. We use this program extensively throughout our organization.

Mike Coles

Re:Open Source Exchange

[Kunta Kinte]

That's interesting. Maybe you should start a fact-finding project. Just by yourself listing your goals and resources you've identified (RFCs, existing source code, API reference guides etc.) If other developers like what you've put together maybe something'll start from there.

I've seen the start and failure of at least one other groupware project, was not pretty :) And I'd say that first step of defining the project in detail is for one or two people only. Others can join later if they agree.

You can take a integrated mail daemon approach eg. http://courier-mta.org/ [courier-mta.org] Which is an integrated ESMTP/POP/IMAP server, and try to add a calender server( whatever that is). Or create the standalone server as you said. I use Cyrus for IMAP/POP and sendmail for SMTP, so actually that way may suit me better. But I suspect starting with something like courier might be better for you.

I know little of exchange, but from what I've seen, I'm not impressed. A lot of functionality I see when someone says "hey, see what exchange can do", I can attribute to any IMAP or LDAP server. Any IMAP server can share folders for instances, etc. The shared calender is missing in OSS though.

Microsoft has release their Mail API, MAPI protocol ( don't know if that's pertinent to this cause ), and there are the free ICAL and MCAL libraries floating around the net for use.

Mozilla has a calendering client, they got it from some company, I can't remember. But it's not going to be in Mozilla 1.0 for sure. You can download CVS mozilla and build it yourself though. http://mozilla.org./projects/calendar/ [mozilla.org.] That could be a good client to start with. Although developing with a mozilla based product can be a chore in inself, since it's hard to exert changes to the process as a non-aol developer.

OpenLDAP as the LDAP server.

I guess my point is, there's a lot of information, choices to be made at first. Maybe if you start by getting it all together and separating the impossible from what's not you might get a decent following?

Re:Open Source Exchange

[ahde]

I was thinking of Bynari as well. Start with using their backend for development purposes -- that would get outlook talking to their IMAP and other features, and try to build an abstraction layer in between, so that you can branch off your scheduling project, and then you could add other features as well. Caldera has a similar project i think, called "Volution" that might substitute, but I haven't heard much about it.

Re:Open Source Exchange

[Christopher Whitt]

I'm not sure how much overlap there will be between your Exchange replacement and the intended Calendar server for Mozilla's [mozilla.org] calendar project. [mozilla.org]

There is already somebody interested [jsoft.com] in starting work on that calendar server. I believe the intention is to use the IETF standards, but if you could work together with the moz people to get an Exchange replacement that also played nicely with standards-based calendaring servers, I'm sure there would be a lot of very happy people in the world. Perhaps, just maybe, you may even be able to combine efforts...

While you're looking at you might hit bugzilla.mozilla.org and look at bug 17048 and 124026 for a slightly unrelated bit on roaming capabilities in Mozilla. I vaguely remember somebody mentioning that it might be nice to connect with a calendar server at some point. It may not have any relevance, but I throw it out for your information.

Squid

[Wesley Felter]

Why is it that Squid always seems to be neglected when people are talking about stable, successfull open source projects - Squid rocks!

Maybe because in the Polygraph benchmark bake-offs, Squid is consistently one of the slowest proxies tested. When compared to other open source proxies Squid may rock, but that's about it.

Re:Open Source Exchange

[Micah]

Well, *ultimately* you'll want Evolution or Aethera(sp?) to be the client, since you're working on an open solution. And open source software could be made to be configurable that way (using seperate servers for different services).

You heard the man!

[Kaypro]

Tell you what, if you would be interested in paying for such a thing, send email to [e-mail] and let us know. :-)

Everyone e-mail Ximian to develop an Exchange like server but only way better!

If this were the case I know I could convince at least two companies I work with to switch their environment to use Evolution/AbiWord/Gnumeric/Galeon/"Ximian Exchange". They would be windows free! I would however wait till they ported everything to Gnome 2 since they would be picky about antialiased fonts. Once these apps are ported to Gnome 2 and an Exchange Like server is built, theres no stopping corporations to switch over totally to an Linux/Gnome shop. It's gonna happen... just wait!

Re:You heard the man!

[__past__]

If you'd want to pay for this, you could also use Sendmail, Inc.s calendar server. It claims to be Outlook-compatible.

Prepare to pay much, though. I dunno what sendmail charges, but it requires Solaris and Oracle to run

MS Exchange server functionality on Linux

[internet-redstar]

MS Exchange server functionality on Linux already exists. It's a great product from Bynari [bynari.com].
It allows all Outlook clients to connect to the Insight Server and delivers full groupware functionality.

In Europe, LIFE [www.life.be] resells this product and assists in migrations

Re:MS Exchange server functionality on Linux

[GoldenShale]

I guess you missed the part about being open source. For a large installation (1500 users) they want $30,000 for the insight server. A GPL'ed exchange type server would be a huge step forward for linux in the workplace.

Re:MS Exchange server functionality on Linux

[stevey]

True but its expensive, and unless I misunderstand things no more open than MS Exchange.

I don't think that the cost is a problem, but I do think there's little point changing from one proprietry application to another - where's the gain?

Pay!?

[Reality Master 101]

Tell you what, if you would be interested in paying for such a thing, send email to [e-mail] and let us know. :-)

You're new to the Open Source scene, aren't you, partner? :)

Re:Pay!?

[sydneyfong]

They're targeting companies who need the exchange server functionality and aren't hesitant to shell out a few bucks for a opensource, windows free version. You're not gonna pay of course. Neither will I, but they're hoping that somebody will be willing to ;-)

Re:Pay!?

[wizkid]

I'll tell you who's paying. Corporations. Corporations are not happy unless they are shelling out money for a supported product. For their money, they want to be able to have there brain-dead "just got MCSE" IT professional call customer support to find out how to fix the box he screwed up. They give the software away free, so that You and I will install, test and hack on the code, thereby reducing the development costs. Over the years, a base of technical people will evolve to support it, BECAUSE IT'S FREE! The subscription model will work, cause over the next few years, corporate america is discovering that the Stock Holders are finally beginning to inforce the idea that earnings and profitability are requirements. $M products are expensive, and $M support is a joke. $M won't be going away, but they will have their monopoly dented. Of course if Collien empliements the 9 state plan, then according to Billy, $M will crumble! (ROFL)

Re:Pay!?

[Tony-A]

Symbiosis can be defined as mutual parasitism.
The software itself might be the same, but there is a vast difference between what a corporation wants to buy and what a hacker wants to buy, as well as a large difference in willingness to pay. If they learn to play together, everybody gains.

Re:Pay!?

[stevey]

You're not gonna pay of course. Neither will I

I don't know .. there are always people that are prepared to pay for things which they find useful.

A case in point; I've written a few mods to popular applications, and even a few programs of my own. Recently I started linking to an Amazon wishlist on a few of the project pages.

To my complete amazement within a week some I'd received one hardbacked book, and one DVD!

(Now if only I could find a decent company who did 'wishlists' and had a nice range of stock to choose from - then I wouldn't have to use amazon).

I guess after making the first post with a link to one of my projects it would be bad to link to my wishlist here [amazon.co.uk], wouldn't it ..? ;)

Re:Pay!?

[aeakett]

You're new to the Open Source scene, aren't you, partner? :)

Open Source != Free (beer)
Are you new to Open Source?

Re:Pay!?

[Reality Master 101]

Open Source != Free (beer) [...] Are you new to Open Source?

No, but apparently you are. Please review the Open Source Definition [opensource.org]. You'll note that clause numero uno is free redistribution. In other words, Open Source == Free Beer.

Re:Pay!?

[dvdeug]

The fact that open source software can be sold
freely does not mean free beer. There's some
software that just isn't distributed freely; ACT
has made wavefront and prereleases of GNU Ada
available only to paying users for a long time.
Another solution is exactly what Ned was talking
about; you get people to pay for the creation or
modification of the software. If nobody pays, the
software doesn't get made; even if it does get
made, the non-payers are the last to get their
hands on a copy.

Re:Pay!?

[Ian Wolf]

You just read the bolded heading didn't you?

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

Open Source has very little to do with free(beer). It never has been and it never will be. Open Source, by the definition you alluded to, is about the openness of the source and the redistribution of that source and/or its modifications. Even the latter is regulated very loosely by the Open Source Intiatives guidlines.

BTW, Nat is not someone I would consider new to the world of Open Source.

Re:Pay!?

[Zordak]

Actually, there are a good number of non-free (beer) applications that are kind of open source to paying customers. For example, buy C++ Builder Pro or Enterprise, and you get the source code for the VCL. It just isn't licensed like the GPL where you can share it with all of your friends and neighbors. There are also some commercial OSs (many of them UNIX derivatives of some kind or another) that use the same philosophy. You pay enough money, you get the source code. I think that even VxWorks, which is almost like the M$ of the embedded UNIX market, sells licensed source code, but I'm not sure (somebody who knows please correct/validate me). It may not be unreasonable for Ximian to set up some kind of system where large enterprise customers pay up and get source code so that they can tweak the thing for their individual needs.

Re:Pay!?

[Reality Master 101]

I usually call things like that "source available" rather than open source, since the latter term has a specific definition.

Di.lute! Dilute! OK?

[jzitt]

5. Rinse, lather, repeat.

Er, that should be "Lather, rinse, repeat", unless you want to walk around all day with shampoo suds on your head. Did anyone do a usability test of the usability testing instructions?-)

Yes, and the results show it

[A nonymous Coward]

See step 2:

2. Coerce an appropriately representative set of individuals into participating in the usability test. The use of lethal force may be necessary.

Not threat -- plaiinly says use. Apparently they had cadavers doing the testing....

Re:Di.lute! Dilute! OK?

[CaffeineAddict2001]

While were at it why not say:
"Lather and Rinse Twice"
We wouldn't want any hapless programming folks getting stuck in an infinite loop wasting valuable time and shampoo.

Sweet!

[xamel]

As for Mono, it is still a technology under development, and the GNOME project has not made a decision to adopt it in any way yet. Work on C# bindings for Gtk is progressing, however, so you will be able to write Gtk and, eventually, GNOME applications in C#.

This rocks! I was always worried that M$ was going to try and stiffle Java (and Open Source) by pushing for its replacement (C#) but now it looks like I won't have to pick sides, I can use C# for Linux AND Windoze dev.
Anything that makes my life easier gets my support. :)

What about Zaurus compatability for Evolution?

[gururise]

One of the greatest Linux PDA's has just recently been released by Sharp. The Zaurus SL-5500 [http] Linux Based PDA has features above and beyond that of other top of the line handhelds.

Will the community embrace this PDA and support it? I find it a bit odd that Gnome and KDE both so throughly support the Palm Pilots; yet, support for the Zaurus is completely absent despite the developer units being availiable since late last year!

Anyone have any news regarding Zaurus Support in Linux??

Re:HERE HERE

[olorin42]

I can't remeber where I saw it, possibly on zauruszone.com or some such. But there is a python script that allows you to integrate the zaurus w/ evolution. It is called evolution.py I think.

On another note, I would liked to have seen real linux desktop support for the zaurus upon release... but they are getting there. Oh well.

Closed community?

[The Evil Beaver]

At the O'Reilly Developer Conference last year on a panel with Michael Tiemann, Tim O'Reilly, and others, Craig Mundie, Microsoft's CTO of Advanced Strategies and Policy, said (I am paraphrasing): "The thing Microsoft does not like about the GPL is that it creates a closed community." Yes, he actually said this, and while the entire audience sat stunned and struggling for oxygen, I remember Tim O'Reilly did not miss a beat, responding with "But so does Microsoft!"

If I were there, I would have been struggling not to laugh so loud as to disrupt everything in a 3Km radius. GPL does not a closed community make.

Just thinking about that makes me chuckle. What does Mundie smoke? :)

Topology Reference Frame

[4of12]

Draw a circle on the white board.

Label the large area outside the circle as "Microsoft". After all, most software Innovation® occurs in this area.

Then, label the inside of the circle "Everybody Else Developing Software".

If you look at the GPL from the standpoint of an individual user/developer in the world at large, ready to share and share alike, the GPL is more a "forced open" community.

If you're Craig Mundie, sitting inside Microsoft, looking for ways of developing products to increase the profits of Microsoft in the same way that's worked for almost 20 years for them, then the inside of the circle is "closed" to you by the GPL.

Of course, IMHO Craig has mislabeled the regions on the inside and outside of the circle...

Re:Closed community?

[Shagg]

Just thinking about that makes me chuckle. What does Mundie smoke? :)

FUD brand cigarettes. They don't give you cancer, they "audit" your internal organs.

Rinse, lather, repeat?

[The Pim]

Uh, has Nat actually used shampoo? If so, it's probably still in his hair....

Looking for a consistent Mono story

[alext]

We are implementing this framework [Mono] because we believe it is important technology, and that the world should have a free, standards-compliant version of it.


More important than Java? If so, why?


Microsoft wants the ".NET platform" to be adopted, which is why they submitted it to ECMA. Whether or not Microsoft will change their minds, retract their submission, and decide that they do not like Mono is not something I can predict...


Interesting how the Ximian people are so consistently adept at dodging the issue of what's really in Dotnet. The fact is that only ~120 of the ~1200 classes currently in Dotnet are standardized, and neither Ximian nor anyone else has plans to clone the rest (Windows Forms, Dotnet ADO etc.), or can risk doing so given potential IP and patent issues.

Bottom line is that Mono is very late and very limited in function compared to Java - OSS supporters would be better advised to put their efforts into supporting Java, Parrot or another platform that has some hope of remaining open.

Re:Looking for a consistent Mono story

[Samrobb]

...neither Ximian nor anyone else has plans to clone the rest (Windows Forms, Dotnet ADO etc.)

FUD.

It took me just a few moments browsing through the mono project plan to come up with this [go-mono.com]:

Using existing components from GNOME.

Our current plan is to implement the GUI tools on top of Gtk+. The only obstacle here is that applications from Windows might expect to be able to pull the HWND property from the widgets and use PInvoke to call Windows functions.

Class Library and Win32 dependencies.

There are a few spots where the Win32 foundation is exposed to the class library (for example, the HDC and HWND properties in the GDI+). Casual inspection suggests that these can be safely mapped to Gdk's GC and GdkWindow pointers without breaking anything.

The only drawback is that support for PInvoke of Win32 code won't be available. An alternate solution would be to use portions of Wine, or even to use Wine as our toolkit.

Initial GDI+ and WinForms implementation

The initial implementation will use Gtk+ as the underlying toolkit. Since GTK+ has already been ported to many windowing systems other than X (including frame buffer, Win32, and BeOS) its use should cover most applications for most users.

Database access

We will implement ADO.NET functionality by reusing GNOME-DB. This is an ideal choice, since GNOME-DB was implemented precisely to provide an ADO-like system for GNOME.

Re:Looking for a consistent Mono story

[alext]

Good, this is a very recent fleshing out of the story, thanks for the update.

However, the fact remains that these are not standardized classes - copying APIs is a risky business and you can be sure that my company won't be approaching MS's legal firepower by basing a product on them.

Re:Looking for a consistent Mono story

[Reality Master 101]

More important than Java? If so, why?

Because Java has a significant amount of brain damage that will never be fixed:

1) Multi-language support is lacking. Just because something can be done doesn't make it practical.

2) Performance is SEVERELY lacking, and will never be fixed. While we don't know what the performance of .NET will be like, we can hope that MS paid much more attention to these issues.

3) The Java language is lacking in many important ways, such as a) an unsigned datatype (an unsigned type is not even supported in the JVM), b) the enforced directory structure for classes, and other things. Yes, you can work around all these things, but why should I have to?

4) Java is NOT an open standard, it is controlled by Sun.

By the way, this is not to say that Java is a horrible language or product. It isn't, and there are many things I like about Java. But the CLR and the CLI are very, very interesting technologies that go way beyond where Java tried to go.

Re:Looking for a consistent Mono story

[pnatural]

5) Java does not treat classes as first class objects.

6) Java is about as polymorphic as a dead cat.

7) Large split between intrinsic types and object-like types.

8) Java does not support multiple inheritance. Sure, "interfaces" help, but they're really only a hack.

9) Javas standard libraries look, behave, and smell as if they were designed by someone fresh out of CS 101.

Did I miss any others? I would have to disagree with you on point 1: Jython simply ROCKS if you're a python-savy person forced to use Java.

Re:Looking for a consistent Mono story

[alext]

5) It treats them as objects, at least as much as Dotnet does. I thought this was meant to be a comparison?

6) Hmmm... perhaps you'd care to elaborate? Again, examples of more useful polymorphism in C# etc. would be relevant here.

7) You mean like the split between reference types and value types in C#? Indeed. See here [geocities.com] for an argument as to which is easier to deal with.

8) Distinguishing types from implementations is a hack? Thanks for the tip - don't forget to pass it on to Jim Rumbaugh next time you see him.

9) What a coincidence - Java happens to be the #1 teaching language so I guess they'll never learn! As a matter of interest, what does the MFC library smell like to you?

Glad you like Jython. A fine example of innovation building on the JVM, unlike Dotnet.

Re:Looking for a consistent Mono story

[pnatural]

5) so you're saying i can pass a class as an argument to a function in java? that's news to me. have you a URL to the javadocs that explains this?

the OP claimed java is brain dead and cannot be fixed; i was elaborating on his point. i don't know why or how you thought this was a comparison to .NET.

6) here's my elaboration: i've never seen a java module of significant size that didn't resort to type casting. a lot. type casting is the antithesis of polymorphism. if the language was truly polymorphic, type casting (more precicely, the level of type casting found in most java code) wouldn't be required.

7) again, i don't recall this being about C#, but instead, about the shortcomings of java. if C# sucks as much as java, well, then that's a shame.

8) no, adding a half-thought-thru feature to an already brain-dead language to give the appearance of multiple inheritance is a hack.

9) so you're saying that the best way to teach people is to give them shitty examples? let me guess, you're from california ?!?!

for what it's worth, i think the MFC library smells worse. :)

and i really do like jython; it gives me an easy upgrade path from java to python.

Re:Looking for a consistent Mono story

[alext]

i don't recall this being about C#... if C# sucks as much as java, well, then that's a shame.

See subject. And yes, it's a shame, or at least, a wasted opportunity.

Polymorphism

[alext]

Actually, I didn't follow this point. Yes, there's a lot of casting in Java, but that's so you can take advantage of polymorphism - cast from a WeakHashList or whatever to a List and then you can pass it to any List consumer.

Or are you thinking of Objects in Collections - would generic classes / templates help? If so, you shouldn't have too long to wait (for Java, longer for C#.)

Re:Polymorphism

[pnatural]

if you're type casting, you're not taking advantage of polymorphism. rather, you're enabling it thru an explicit operation that says "i think this object is of this type, and i want to treat it that way". (i'm sure some purist will pipe up and correct this, but please just bear with me).

the point of contention is the type casting: if you have to explicitly state that you're using an object of a specific type, you're not really allowing that objects type to vary (aka, be polymorpic).

put another way: type casting is casting into stone, but true polymorphism means you don't really care about the type as long as the object supports the operations you expect it to.

i haven't had enough coffee this morning, so i could still be wrong. :)

Re:Polymorphism

[alext]

Hmmm, I think the logic is a wee bit tangled here:

When you say "you don't really care about the type as long as the object supports the operations you expect it to" this is true for the original type of the object - a WeakPinkWobblyHashMap, say - but you do care that it's a Map, because you're about to call Map operations on it.

So you either do this by declaring a Map parameter, or accepting a superclass (such as Object) and downcasting to a Map - which might throw an exception if the object isn't a Map.

It's downcasting that's a problem in all code, but I don't think Java does any worse than any other language in this - templates/generics are the only thing that would help and they can still get very messy.

Personally I don't dislike the

Map m = new HashMap(1024);

style, because of the chance you have to use subclasses on the right, though it is noisier than typical statements in other languages.

Re:Polymorphism

[pnatural]

The original point is the same: if you don't worry (or don't have to worry) about the type, then you can be polymorphic.

python file-like objects come to mind. in python, it's trivial (and common) to implement the most used methods of file objects in a new class and then use the new class as a substitute for a "normal" file object. a good example of this is console logging. sys.stdout and sys.stderr can be replaced with objects that log to a database or the filesystem. as long as new objects maintain the correct method signatures (granted, by convention only), they interoperate with existing code -- all without type casting or even type checking.

Re:Polymorphism

[alext]

Cue 100s of language pedants to leap in and say that you are referring to dynamic typing rather than polymorphism. Java is statically typed, which means that it eliminates run-time type errors, unless you use downcasting (or operations that can throw UnsupportedOperation exceptions), but the penalty is that you have to label all your variables with their type, unlike Python.

There's a rather dated discussion here: Object FAQ [cyberdyne-object-sys.com]

Re:Looking for a consistent Mono story

[pnatural]

but a decision taken when designing the language.

oh really? i thought interfaces were included well after the initial design. i'm by no means a java follower, and therefore could be wrong.

Re:Looking for a consistent Mono story

[alext]

1) As has been pointed out countless times before, the CLR isn't really multilanguage - it just supports languages than are semantically equivalent to C# with a common set of types.

2) Performance of Java 1.4 is far better than the current C# SDK, believe me on numerically-intensive stuff they're not even close - this is what one would expect from a mature VM. However, there is no fundamental limitation in either Java or Dotnet - they can both be JIT compilers - though Java is currently more intelligent since it can factor in dynamic statistics, such which branches are commonly taken, whereas Dotnet is a static-only compiler.

3) a) An unsigned datatype? Are you serious? This is utterly trivial. Anybody pointing to this sort of language feature as a significant differentiator is clearly unfamiliar with genuinely alternative programming paradigms - functional, logic-based etc. Don't they teach LISP in college these days?
b) Directory structures? Well, I have never anyone complain about this in 4 years of programming Java - if you can point to an actual problem I'd be fascinated to see it.

4) Java is controlled by the JCP. You can read about it here: http://jcp.org/home/index.en.jsp [jcp.org]. If you think MS is about to give up control of the Dotnet platform to other vendors you must be under the influence of something more pernicious than mere naivety.

Re:Looking for a consistent Mono story

[Reality Master 101]

As has been pointed out countless times before, the CLR isn't really multilanguage - it just supports languages than are semantically equivalent to C# with a common set of types.

True in a sense, but the point is that it's MUCH better at multilanguage capability than Java. In fact, there are quite a number of functional languages targeted for the CLR. Is the CLR the ideal environment for a functional language? Obviously not, but it's certainly better than the JVM. MS decided early on that multilanguage was going to be a design feature.

Performance of Java 1.4...

Yeah, yeah, I know. Every release Java people say the same thing. Java 1.3 was the last one I used for an XML-heavy project. Using Sun's own software, the XML libraries were AT LEAST 100 times slower than equivalent C code. Java is absolutely atrocious when it comes to string processing, which is really processing that is heavy on iteration.

I don't feel like getting into a big treatise on why the JVM will never be fast, but trust me, it will never be fixed. It's intrinsic to the design that it will always be slow. This should be pretty obvious since they've had eight (?) years to get it right and they still haven't solved it. But hey, maybe I'm wrong -- maybe 1.4 is the "magic" version. I highly doubt it, though.

An unsigned datatype? Are you serious? This is utterly trivial.

Utterly trivial unless you're going to do anything serious. Yes, you can code around Java's lack of an unsigned type. But it's a pain in the ass and forces you to use larger (aka slower) datatypes.

Java is controlled by the JCP.

Uh huh.

Re:Looking for a consistent Mono story

[alext]

I don't feel like getting into a big treatise on why the JVM will never be fast

I completely understand your position on that.

>An unsigned datatype? Are you serious? This is utterly trivial.

Utterly trivial unless you're going to do anything serious.

I'll keep it in mind if I find myself doing anything serious in my next 20 years in IT.

Re:Looking for a consistent Mono story

[Reality Master 101]

I'll keep it in mind if I find myself doing anything serious in my next 20 years in IT.

Maybe "serious" is the wrong word, but if you don't see the need for an unsigned data type, you have never done any complex or low-level programming. Sorry, but just because someone writes Cobol reports for 20 years doesn't mean they're qualified to discuss these issues. Or writes Java programs to move data from one database to another.

Re:Looking for a consistent Mono story

[alext]

ROFL. I wrote a large portion of the CORBA specifications, as it happens, and was building OO systems in Smalltalk 12 years ago that can still put Java and Dotnet systems into the shade.

But of course these developments are nothing compared to the revolution that would follow the introduction of unsigned ints to Java. Can't wait...

Re:Looking for a consistent Mono story

[Reality Master 101]

ROFL. I wrote a large portion of the CORBA specifications, as it happens,

There are a lot of people who write specifications who never do any significant implementations of anything themselves.

and was building OO systems in Smalltalk 12 years ago that can still put Java and Dotnet systems into the shade.

Oh, well, if you're a Smalltalk expert... yeah, there's a language that took the industry by storm. (not that it wasn't influential in its own way, of course).

But of course these developments are nothing compared to the revolution that would follow the introduction of unsigned ints to Java. Can't wait...

I never said that unsigned datatypes are "revolutionary". I only said that the language was brain damaged for the lack of them. I also said that, yes, you can code around them.

Re:Looking for a consistent Mono story

[sinserve]

>There are a lot of people who write specifications who never
>do any significant implementations of anything themselves.

Herbert Schildt was in the C standardization committee, and his C
books are almost always "NOT RECOMMENDED" by the ACCU.

--

Re:Looking for a consistent Mono story

[Reality Master 101]

Herbert Schildt was in the C standardization committee, and his C books are almost always "NOT RECOMMENDED" by the ACCU.

An excellent example, although I have to admit to owning one Herbert Schildt book, The Annotated C Standard. For awhile there, it was the cheapest way to get a copy of the C Standard. You just have to ignore the annotations (many of which are wrong). :)

Re:Looking for a consistent Mono story

[Tony-A]

Unsigned data type.
Personally, I like machine code and bit fiddling, but all an unsigned data type buys you is the ability to store one more bits worth of signed data. This is at the expense of very nasty logical problems combining unsigned values with signed values and storing the results as signed or unsigned values. The opportunities for subtle michief are enormous.
Unsigned data can be very useful, but it tends to be VERY machine dependent. At the extreme, porting between VAX and IBM can require algorithm redesign and restructure just to get overflow detected properly.

Re:Looking for a consistent Mono story

[sab39]

More important than Java? If so, why?

No. Equally important as Java.

They are both closed, proprietary platforms that nevertheless have significant technical merit. Both are for all practical purposes under the exclusive control of large companies. Both have almost identical advantages (technical elegance) and disadvantages (performance). There are minor differences (slightly better multi-language support versus slightly better multi-platform support) and major similarities (the bytecode definitions can be matched up almost opcode-for-opcode).

Both have active Free Software projects attempting to clone them. In fact, both have multiple competing active Free Software projects attempting to clone them (Mono vs Portable.NET, Kaffe versus gcj versus ORP/Classpath (although Classpath and gcj cooperate a lot)).

What was your point again?

(The rest of your article is pretty much pure FUD so I'll ignore it. The only platform that's currently open (let alone "remaining" open) is Parrot, and that doesn't really work yet)

Re:Looking for a consistent Mono story

[alext]

Equal? Not equally mature - or do you seriously want to compare Mono with Sun's 1.4 JVM on Linux? And not equally innovative - Java introduced all the significant advances years ago, Dotnet is pathetically derivative.

So the point is, in case it escaped you, the platform should I be writing my OSS app for is Java. Mono proponents have never demonstrated substantial technical benefits of Mono over Java, certainly not sufficient to justify entanglement with MS's lawyers - it's just a bandwagon.

Re:Looking for a consistent Mono story

[sab39]

You may have misinterpreted my position. I program in Java every day. It's my favorite language out there. I do write open source software [wuffies.net] in java.

But it's unfair to say that Java on an open source platform is mature. Sun's 1.4 JVM is not open source, and although they have made encouraging baby steps in the past couple of weeks, it still seems unlikely that it will ever be.

The JCP is a nice gesture but you can tell that Sun still really call the shots when they were able to shut down a JSR Leader when he wanted to make the reference implementation open source. The person who enforces the rules can do anything, regardless of what the rules actually say (the same reason that the US government can often blatantly violate the Constitution, despite being theoretically bound by it).

So that leaves the Open Source java implementations. Anyone claiming that Kaffe, ORP, Classpath or gcj are mature needs to try them for real work. Last I tried, NONE of them could even run Tomcat, which is one of the premier open source java applications. None are even close to beginning to think about having Swing, and even AWT is iffy for most of them.

So if you're concerned about Open Source or Free Software from an ideological standpoint, you probably shouldn't write in Java, unless you're willing to live within the limitations of the current implementations. Same goes for writing C# software for Mono or P.NET.

As Nat quoted ESR as saying, when faced with a problem, the Open Source community by its very nature pursues all ways of solving it at once. Thus we have three open source Java implementations, two open source .NET implementations, and Parrot. This is a good thing, because whichever one turns out superior in the long run will survive. None of us can predict what that might be.

I personally hope that all three do well, and that we eventually end up with a runtime that can run code written for all three, and integrate them together. There are already signs of this, like the jilc project which translates Java bytecode to .NET IL, and various (mostly commercial, I think) projects that do the opposite.

I'm not bashing Java. But I see no reason to bash .NET either. Or GNOME. Or KDE. Or vi. Or Emacs. The beauty of Open Source is the availability of choices. Please don't try to take those choices away, even if they aren't the choices you'd make.

Re:Looking for a consistent Mono story

[alext]

Alright, some reasonable points IMHO. Diversity is popular on /., more so than consistency, so I can see how the more is better argument will appeal to many.

However, though it might be possible to merge the JVM and CLR, a merger of the associated libraries is much less likely. In particular, it's hard to justify the effort in swimming upstream and trying to clone Windows Forms for Gtk when IBM is already
producing Java SWT for Gtk. What's the point? As soon as you've got a complete clone, you'll get sued - how does that help anyone?

I prefer diversity to be limited to real, technical diversity - Perl vs. Java, or Scheme vs. Visual Basic, or an AST-based IL vs. a bytecode IL. C# and Java are so close that the choice of one over the other won't be based on language characteristics - only the most pedantic advocates would see meaningful differences.

Re:Looking for a consistent Mono story

[sab39]

Granted, there's not much value from a purely technical standpoint in having two different solutions to essentially the same problem. But there's an argument to be made that this can be useful even where the essentials are very similar (there actually are a few things from C# that I'd like to see Java pick up, like foreach, auto-boxing, and property support that's are more than a naming convention).

If a programmer from windows a year or two down the line from now is familiar with programming in C#, it'd be nicer for him to be able to simply carry over that knowledge than to have to say "well, Java is exactly the same as C# except that all the keywords have different names, and these few other differences".

Similarly, if some open source software is written to the JVM (like the Java JUnit test framework, for example) it'd be nice for it to be available directly from C# rather than having to port it (and end up with a forked project like NUnit - there are a bunch of projects like this which are straight ports of Java projects to C# which seems silly to me).

The problem of libraries is probably unavoidable but I don't think it's so awful to have two runtime libraries loaded at once. Many people already keep multiple windowing toolkits loaded - a theoretical disadvantage in exchange for the real practical advantage of being able to use applications written by someone who disagreed about which toolkit was better.

I'm arguing for diversity in programmer choice, but that doesn't mean I think that consistency is worthless: I'd rather that the various toolkit makers could get together and make their toolkits able to use each other's themes, for example, and do so automatically as needed. In the same way, having a runtime environment that could pick up the libraries native to the other language would be nice. And of course the user should never be able to detect any difference between a Java app and a C# one.

(Your argument about Windows.Forms is internally inconsistent, btw, because it would suggest that IBM should never have written SWT in the first place because Swing was there first. Obviously they thought writing a new toolkit was worthwhile for some reason. Obviously the Mono people feel the same way about writing a Windows.Forms port. You can argue the legitimacy of the reasons, but you can't base your argument on the premise that if a toolkit already exists then writing a new one is pointless. And a point about getting sued doesn't belong in that argument either.)

Re:Looking for a consistent Mono story

[alext]

Inconsistency is bad wherever. If IBM did SWT for purely political reasons then that's a problem - the jury seems to be out on this one - but that doesn't give others the excuse to arbitrarily duplicate things further.

Because Java was here first, and C# adds nothing from a technical standpoint, you've ended up arguing how OSS developments (JUnit etc.) can enhance a proprietary platform rather than how non-proprietary systems might benefit.

The problem is that we're years away from this relationship being equitable. Applications like Photoshop are not going to be available for Mono for a long time, if ever. Meanwhile, Dotnet gathers developer support with your help.

Include me out.

Re:Looking for a consistent Mono story

[sab39]

With regard to SWT, it doesn't matter why IBM developed it. You argued that developing Windows.Forms was bad because SWT existed. By that logic, developing SWT was bad because Swing existed. You need to present another reason why you think that developing Windows.Forms is bad. Your "inconsistency" argument doesn't work either because SWT is "inconsistent" with existing and working Swing apps.

I think you're still missing one of my major points, which is that Java is just as proprietary as .NET. You can't argue that Open Source developers should embrace one and reject the other for that reason. See the bit about the JCP in my previous comment.

By my logic, if I'm running JUnit on Sun's JDK, I'm benefitting a proprietary platform. If I run NUnit on Mono, I'm not. If I run NUnit on MS's CLR, I am; if I run JUnit on Kaffe, I'm not. I'm not saying that's the only way to think, but it's not internally inconsistent - honest :) And since most people probably run JUnit on the JDK, that means it's already benefitting a proprietary platform.

I don't believe Mono gives anything to .NET. I also don't believe Kaffe gives anything to Java, as evidenced by the way that Sun consistently refuses to acknowledge its existence. The reason for developing Mono (and Kaffe - which btw is my example free java implementation just because it's the easiest to type) is because we (Open Source developers) get a benefit from it: The ability to lure developers from windows, the ability to run .NET applications from windows, another option of programming language to use (and it does add some useful features over Java, even if they are minor. One of them might be extremely useful for a particular project). And since existing Open Source Javas are still so immature (after 5 years or more!) it's hard to argue convincingly that they'll be mature before Mono is.

Unless you're claiming that Java is open (which it isn't in my book, although I accept your right to disagree), the only argument left for why Java should be embraced and .NET should be eschewed is that Java was here first. And that isn't a good enough reason for me.

Re:Looking for a consistent Mono story

[alext]

Nope. You're putting words into my mouth.

Developing Windows Forms is bad because it:

a) overlaps with Swing, AWT, SWT (and for that matter, WFC)
and
b) makes users vulnerable to IPR attacks from MS

As you strenously and repeatedly point out, SWT would be an equally bad in duplicating Swing, but only if there were no technical justification for it. However, judging by the number of 'Swing is slow and ugly' complaints here on /., I think you'd have a hard time proving that was definitely the case.

I do not accept that Java is anywhere near as proprietary as Dotnet. The number and size of companies producing Java products (not just products based on Java) is clear proof of that. Yes, Sun and IBM and others have IPR, but they do not constitute an aggressive monopoly, and the worst that can happen is that a product has to license that IPR on the same basis as partner companies. With MS, there's no guarantee of a license at all.

If this bothers you, I would suggest you try Parrot etc. In any event, none of this can make the case for embracing Dotnet.

Yes, Sun benefits from JUnit just as MS benefits from NUnit. However, because of the lead Java has established, and the remote possibility of mainstream Dotnet apps running on Mono, the flow of OSS value is going mostly from Java to C#. Once you and your buddies have helped establish Dotnet as the dominant platform, not because it offers any compelling technical advantage but because you got bored with Java, the Java economy will die off and MS will be in the driving seat of Linux development.

Lastly, in case it isn't obvious, the reason that Kaffe is immature is that high quality JVMs are available for Linux from both Sun and IBM (and soon BEA). In the unlikely event that IBM decided that its $1B investment in Linux wasn't a good idea, Kaffe could be revived. However, this is about as likely as MS supporting the complete Dotnet platform on BSD.

So to sum up, Java should be embraced because:

1) Already mature technically
2) People know it
3) Built-in cross-platform support (no Windows Handles and backslash-only paths here)
4) Linux support from vendors
5) The whole Java platform evolution and IPR is somewhat open. This avoids the trap set by MS where a little bit of the platform is offered to a passive standards body and the rest kept proprietary.

Re:Looking for a consistent Mono story

[sab39]

Okay, then we've got to the core of our difference, which is that you consider Java "open enough", and I don't. I think that both of our positions are entirely self-consistent given that core disagreement. If I was happy with the openness of Java, I'd probably feel about the same as you do - that Mono is a waste of time.

I don't think I'd ever actively advocate that people stop working on it, though. If people working on something they want to work on poses such a great threat to my position, whatever that position is, then I'd probably consider that my position isn't as strong as it should be, and re-evaluate it. To be fair, I don't think you've actively advocated that people stop working on it, but rather advocated that people embrace Java instead, which is different.

First thoughts

[The Cat]

I have to say that Linux in general and desktop software in particular have made unbelievable progress in just the past year or two. Gnome only looks to be improving. I'm not sure what I think of Mono yet, but I can say that I am not even remotely interested in .NET, and here's why:

I did VB development, among other things, for about 7 years. I started with version 3 (on three floppies on a 386/25) and worked on every version through VB6. I pushed VB about as far as it could be pushed (DirectX calls, BitBlts, API, simulated inheritance, etc.)

But one day, I embedded the SHDOC control (web browser) in a program I was writing. Not thinking much about it, I built a setup file, and then tried to install it on another machine. When the form opened, a dialog box appears "This program requires the latest version of Internet Explorer, would you like to upgrade now?" or something similar.

I thought to myself, "so now *my* program is promoting IE??? Huh?????" Nothing in the development process said anything about this. Needless to say I was not only confused, but a little annoyed.

I was never really all that impressed with VB (or Windows development) from that point forward. I've never seen anything like that with any other development system. I'm far more intrigued with Linux, because it is a great web development platform, and it has some hugely improved programs which have become available recently.

For example, I just spent a couple of days drafting a document in Openoffice. As far as I could tell, the program has all the features necessary to write good documents (formatting by paragraph type, header/footer, page numbering, proper graphics support with the possible exception of PNG in some cases), and, unlike my ancient 16-bit version of WordPerfect, it doesn't crash on page breaks and between graphics.

After drafting, I e-mailed it using Evolution, which has every feature I remember from Outlook (and some new ones).

Now I'm typing this comment on Mozilla, which, AFAIC is the best web browser I've ever used, and it looks to be improving.

I'm very much looking forward to learning Python, PyGTK and XUL in the next few months. This covers everything that I remember "needing" Windows for.

At this point, I would look at anyone managing an IT or development project who rejected use of Linux out of hand as irresponsibly ignorant.

Maybe I'm missing something, but from here it looks like Linux is doing just fine on the desktop... wait, EIGHT desktops. :)

Re:First thought

[Anonymous Coward]

>> After drafting, I e-mailed it using Evolution, which has every feature I remember from Outlook (and some new ones).

I haven't reinstalled Linux yet, which is clearly a bad thing, since I was reinstalling Windows once every few months. I recently figured out why.

Since moving to Linux, I've been using Evolution. But there _is_ a feature missing from it compared to Outlook: the automatic feature that schedules a reinstall of my operating system whenever I open certain emails.

Evolution is clearly inferior in this regard, and it is my hopes that Ximian will pay more attention to little details like this. Otherwise, less open minded people than me might not consider using Linux if their favorite features are not available.

Re:First thoughts

[The Cat]

If it didn't include all the IE DLLs that you used in the app, then yeah, I'd expect it to do something like ask the user to download them. Actually, that's a more graceful reaction than I would expect.

Well, the OCX control for IE was included, apparently, but I guess that version of IE wasn't installed on the other machine, so it insisted that IE be installed. That bothered me because this program just suddenly became an advertisement for the latest version of IE, and I had nothing to do with it.

Now if the Grid control or something were missing, you're right, I would expect the program to just pop up a red X dialog and crash.

Re:First thoughts

[Danse]

That bothered me because this program just suddenly became an advertisement for the latest version of IE, and I had nothing to do with it.

Well, you did have something to do with it, in that you used the IE functionality made available by the ActiveX OCX or DLLs. It might have been possible to update the user transparently when installing the app if your setup package is created to do this. I've never actually used IE in an app yet, so I wouldn't know the exact procedure for accomplishing this. Then they wouldn't even need to know that IE was being updated. It would, however, be nice to alert them to this fact before the installation commences.

Re:First thoughts

[The Cat]

Well, you did have something to do with it, in that you used the IE functionality made available by the ActiveX OCX or DLLs.

Which should not have then proceeded to "upgrade" themselves on someone else's machine. It makes it appear as if my program is only a vehicle for MSIE upgrades.

Turns out VB is full of little surprises like this. The "setup kit" is whole 'nother adventure (that works about 60% of the time), for example.

Re:First thoughts

[The Cat]

It wasn't just the control. It wanted to reinstall IE completely.

(Slow down Cowboy is getting REALLY old)

Thanks Nat!

[Khan]

Talk about one of the better Q&A's in here in a while! And on the subject of an Open Exchange type server, group email and scheduling is one of those areas that has lacked in Linux, IMHO. And if it would allow Outlook to connect to it, you'd have a MAJOR winner on your hands!

Way more interesting than Miguel's interviews...

[kalifa]

I have nothing against de Icaza, but, boy, there's quite a difference of class between this interview and De Icaza's interviews. Finally, Gnome has a spokespersion who actually takes the time to think before giving an answer, and to provide long and thought-out answers when necessary.

Besides, no provocative statement, no unjustified arrogance, no fake enthusiasm... I'm impressed.

why does Ximian overwrite my menus?

[jchristopher]

My question didn't make the original cut, so I'll ask it again here.

Why does Ximian feel the need to overwrite the existing Gnome menus when I install their software package? As a newbie, this was VERY frustrating. I was just getting used to the system and learning what was included.

When you install Ximian, they wipe out your existing Gnome menus - if you don't know the command line name of the programs, those programs are effectively 'gone'. Very frustrating.

Is there any reason you guys couldn't just put everything in a submenu called "Ximian"? Or maybe move the old stuff to "Old Menus"?

Frankly this smacks of Microsoft - "you didn't need those other programs anyway..."

Re:why does Ximian overwrite my menus?

[pmora]

Ximian doesn't overwrite them, they just hide them. You can get them back by going into the Control Center and selecting Desktop -> Panel -> Menu. You'll see at the bottom of the "Global Menu" list the old GNOME menu; simply enable it again.

Do a little poking around before pointing fingers and using the M-word. :-)

Re:why does Ximian overwrite my menus?

[GauteL]

They don't wipe out your old menus. They introduce a NEW menu that is used as default. If you right click on the foot-menu you can choose what menu to use. I think you can do the same from the control-center, but I'm not sure because I've moved to GNOME 2.0 recently.

Usability!?!

[Crispy Critters]

This one almost made me snort in my coffee...

Ximian and the GNOME project have learned from standard, existing industry practices for building usable software.

Existing industry practices?

This one is a real problem...

The results of the comprehensive GNOME desktop usability study that Sun performed last year are worth a read

I read the study, and it was terrifying. The conclusion was "anything that is not identical to MS windows is confusing." People in the study were all windows users, and any deviation from from the way windows menus, icons, hotkeys, etc. worked was considered a point of confusion and therefore a flaw in the interface.

Usability flows [from] predictability which flows from consistency.

Consistency and predictability are not the most important parts of the user interface. This claim denies the obvious fact that we learn to use these interfaces. This is the argument that leaves us all using the qwerty keyboard today. Simply repeating the sins that have given us the crappy interfaces we have now (because we are used to them) is not "usability".

Can the ximians speak the truth, and say "For business reasons we have to make our interface as similar to windows as is legally possible"? I can accept that, as I can accept any honest statement.

No, no, no...

[zapfie]

Nat:

Open source software is a threat to Microsoft's business model, and it is a competitor which they cannot attack with their traditional maneuvers.

It's not Ipen Source that's the threat, it's Free Software. FreeBSD is open source, but you can turn around, take that code and put it in a closed commericial product, and sell it without ever releasing your source. I'm not going to argue the points of different licences, but anything Microsoft can take the code from and not have to give back, they aren't going to see as a threat.

Yes, yes, yes!

[Nailer]

It's not Ipen Source that's the threat, it's Free Software. FreeBSD is open source, but you can turn around, take that code and put it in a closed commericial product, and sell it without ever releasing your source.

The BSD license is a Free Software license as it conforms to the Free Software Definition [gnu.org] it's also Open Source as it conforms to the Open Source Definition [opensource.org]. Why do so many people who talk about licensing as being important seems to never have read any of these documents? Half of Slashdot uses `commercial' as a way of saying `non-free' or `closed' or `proprietary'. News Flash: Red Hat, like all businesses, are aiming for money (and getting it). Commercial apps are very often both Open Source and Free Software.

I'm blacking out again now, as I've been banned from moderation because I disagreed with a Slashdot editor.

Hmmm, irony

[yatest5]

(amid general rant about how quotes should be in good grammatical language)

I KNOW this has quotes so can be in 'natural language',

asphincter says what?

Re:Talk sense, not sensibly

[CodeMonky]

What the hell are you doing quoting someone off a slashdot interview to your bosses? Honestly, I don't think he took this interview expecting to win over PHBs. Just answer some questions from the community that already supports them.

There are plenty of good open source keynotes out there, look at some of the keynotes from past O'REilly conferences.

If you are gonna take a quote off a geek site and expect that to persuade your boss to buy something than you don't really have a shot to begin with.

Re:Talk sense, not sensibly

[waldoj]

In the first 100 words of this piece we have the phrase "And we were like: this just ain't right.".

You ain't from these parts, are you? Nat's a southern fella', from Virginia. I suggest you stay up north. You come down here talking like that and you won't get far. Sounds to me like you're all hat and no cattle.

-Waldo Jaquith

Re:Talk sense, not sensibly

[Craig Maloney]

I'm not a speech major, nor do I portray one in my corporation, but I believe one of the key rules of delivering a speech or an interview is:

Know your audience.

I think saying "this ain't right" in this forum is appropriate. Would you have taken him more seriously if he had said "We need to change this. This isn't correct, and has never been correct. How can we leverage this into a positive win-win situation, while minimizing detrimental side effects and still maintain a positive outcome?"

I think you have your answer...

Re:Talk sense, not sensibly

[The Cat]

Nothing wrong with an occasional colloquialism.

Then again, seeing a 55 y.o. PHB outside a meeting would be an incredible event, so there you go.

Re:Talk sense, not sensibly

[BreakWindows]

Open source wins again. Finally ridding the world of a bunch of starched-shirt marketing geeks trying to "form interesting synergies" and provide me with a "robust solution", a "feature rich" environment and "streamlined efficiency".

They care more about what they say than the marketspeak they use to phrase it. Unlike the geeks at the big companies (and smaller consulting firms, and half of Slashdot's readers), I hope more people don't feel the need to hide behind stupid marketing buzzwords in the future. Reading a Microsoft press release is like listening to a George Carlin act, only without "the funny".

Re:GNOME is not a Standard! We need a Standard!

[Telex4]

OTOH, the sector that has true competition - the Open/Free software sector - is mired in backwardness and incompatibility, not to mention its complete lack of capitalistic viability.

A lot of Free Software is incompatible with software produced by various companies who refuse to openly publish their document formats and other necessary standards, such as Microsoft Office documents (even OpenOffice has all sorts of nasty problems converting to a fro). Software whose source is openly available is actually more compatible by its vey nature. And few users care about it's ability to make money, and some companies make money from it. Who cares if its capitalist? Y'know capitalism in its current form has only been around for about 50 years or so, and people got on fine before then. Not *everything* has to conform to one narrow-minded standard to be a success.

The desktops (GNOME and KDE) are so different it's not even funny. I'd rather write an application to work on both Win3.11 and XP than one that's supposed to look good on both GNOME and KDE.

Ah, something on-topic. Now I run a mix of Gtk-based and Qt-based apps on my desktop, both in KDE (mostly) and GNOME (occasionally). The only difference in looks I find is the window decoration. The difference for programmers? None, unless they put in desktop integration features like applets. I'd love to seee the same said about Windows 3.11 and Windows XP by a Microsoft engineer.

Now the only thing, looks wise, that is a problem between KDE, GNOME and all the other desktop envionments and window managers is something touched on in this interview, but which you neglect to mention. That is that the various themes, window layouts, menu positions and mouse/keyboard button bindings can confuse a user coming from Windows to GNU/Linux, or from one desktop environment to the other. It's something that's slowly being addressed (look at KDE3+GNOME2 and then look at KDE2+GNOME1 to seee how far they've come).

All you web designers expierance a similar problem, to a smaller degree, working between all the wacky Open Source browsers.

I've been developing web sites for about 5 years now, and I can tell you that since working in GNU/Linux and being forced to adhere to standards (the topic of your post), I've never had it easier. Mozilla, Galeon, Netscape, Konqueror, Lynx and any other browsers you care to choose all render the W3C specifications without a hitch, and the first four all handle javascript, java and flash fairly well if you're feeling evil. What makes designing Web Pages a nightmare is trying to get things like DHTML, complex javascript and other non-standard features to look right between browsers.

Now as you say, GNOME is not a standard, but we don't need one single standard. Even Microsoft Windows isn't a single standard: it is a whole load of standards put together by experienced teams with loads of usability testing time, stuck into one product. If you buy a boxed copy of SuSE 8.0 you'll probably get a similar impression...

Linux Tools are written by people with ADD

[chiph]

I have to concur. After making a couple of starts at Linux development (I'm a former OS/2, current Win32 programmer), I just threw up my hands in frustration and starting learning about .NET. Why?

Because there is NO UNITY of VISION in Linux!!

I *want* to develop for Linux. I *like* the idea of open source. But it seems to me that that people who develop tools for Linux are all suffering from Attention Deficit Disorder. They start projects and never finish them!

Why can't they standardize on something as simple as command-line parameter prefixes? Is it a single dash, or a double-dash, or something else?

Chip H.
(No, this isn't flamebait - it's an opinion)

Re:Linux Tools are written by people with ADD

[psamuels]

Because there is NO UNITY of VISION in Linux!!

This is true. If you require unity of vision, you need to look at a single-source lock-in solution. These days, that pretty much means Microsoft.

But it seems to me that that people who develop tools for Linux are all suffering from Attention Deficit Disorder. They start projects and never finish them!

Also true. A majority, perhaps even a vast majority, of open source projects are never finished - but then, by what definition of finished? Many projects are quite usable and IMO could be considered feature-complete, without ever hitting the magic "1.0". (My browser, links, is only at 0.96 but has been quite nice since the mid-0.80s.) Some projects get developed to the point of being feature-complete and reasonably bug-free, but never achieve the spit and polish expected by non-programmer users - since the developers are themselves interested in neither spit nor polish. Other projects never get to be actually usable, or never overcome major limitations in functionality.

Why can't they standardize on something as simple as command-line parameter prefixes? Is it a single dash, or a double-dash, or something else?

You mean like the DOS/Windows world, where sometimes you use /OPTION, sometimes -OPTION, and the /OPTION usually comes after filename arguments, but occasionally before filenames, and the /OPTION is usually but not always case-insensitive, and usually a single command invocation can only handle a single filename argument, but a few tools can take a list of filenames, and tools that expect a filename usually do not, but occasionally do, have a default mode of operation for "no filename", and the filename itself usually, but not always, undergoes wildcard processing, and it is usually, but not always, necessary to quote filenames with spaces?

If you're looking for command-line consistency, you won't find it in Unix or in Windows. Perhaps the functions of the programs involved are too divergent to support a common "interface".

As to single-dash versus double-dash, it's historical. Double-dash exists because that way a program can unambiguously support long option names and option clustering. Programs for which option clustering is not as practical, like gcc, sometimes use a single dash with long option names.

Re:Linux Tools are written by people with ADD

[spitzak]

Just to point out redundantly that there really are standards:

Use a single dash for single-letter switches, ie -a, -b, -c. This lets you turn on all three by using -abc.

Use double dashes for descriptive word switches, like --backup, this avoids these being considered -b -a -c -k -u -p.

Many programs only support one switch per dash, which is incompatable with the standard. These usually don't care how many dashes you put in front.

In any case you have got to be kidding if you think Windows is better for consistent command line switches. Certainly there are things there that are more consistent but you managed to choose the worst possible example for Windows! Hint: what and how do you use forward slashes? When do you use an equal sign? What glob expressions are accepted?

Re:GNOME is not a Standard! We need a Standard!

[Melantha_Bacchae]

Brontosaurus Jim wrote:

> But even further: Just look at the whole vi/emacs war. All the vi
> people simply refuse to bend to emacs (LOL, obviously they don't
> know lisp!) and the emacs people generally ignore the vi people
> (which isn't all together unwarrented - just rude). This isn't helping
> anyone. All the vi people should start putting work into Emacs, maybe
> making a compatibility mode, so we could have one large, perfect
> piece of software, instead of two half-assed implementations.

I honestly don't know where you've been all this time, but I was using Emacs in vi mode back around 1989-1990. Before the web, before Linux, in Windows' infancy, Emacs had a vi emulation mode. I just checked my version of Emacs that runs under Aqua on OS X and guess what, it has three vi emulators to choose from!

Emacs is a complex programming environment from the command line only days. It is extremely powerful. Vi is a nimble little editor that is great for making quick changes to things (without killing your hands with a lot of control key antics). BBEdit is a wonderful Mac editor with great html and perl support. Project Builder may skimp a bit on features, but makes it very easy to make OS X programs quickly. I use them all and love them all.

The only time there is a real question of either/or is if one of the choices is the tool of an evil empire like Microsoft's Visual Studio.net. Anything else is a matter of an individual's personal preferences, and should probably be respected. Unless, of course, the "war" is strictly for fun. ;)

"The path of peace is yours to discover for eternity."
"Mosura", 1961

Outlook UI a pain in the arse!

[Chuck Chunder]

Or at least there are so many little quirks that just make it annoying.

For example when you want to copy and paste part of the "From:" line in an email. You can only copy someones whole name/address. This gets even more annoying when the addresses come in with quotes around them.

And besides, it doesn't have vfolders, or a quick way of creating a filter based on a message. Evolution may _look_ a lot like Outlook, but don't think that looks alone make up a UI.