Slashdot Mirror

Please read this:

http://www.rants.org/2017/11/c...

for a possible answer to your question. I'm surprised this isn't linked to from the main article.

Full disclosure, I'm on the Board of Directors of SFC.

There is a good answer to this here, which I'm surprised isn't linked to from the main article:

http://www.rants.org/2017/11/c...

Notably:

"These paragraphs are disingenuous in several ways.

First, Conservancy has consistently been willing to meet, but merely insisted as a ground rule that the conduct of the meeting must be professional and civil. This was both responsible and a smart move on their part. The meeting isnâ(TM)t going to be productive if it involves shouting and insults, and they had reason to believe that was a real possibility.

If you donâ(TM)t know the personalities involved here, you might not understand why such a ground rule would be necessary. Let me simply say this: I have known Conservancyâ(TM)s Executive Director, Karen Sandler, for a decade now, and worked very closely with her on a number of efforts, some of which involved contentious counterparties. I have never seen Karen lose her temper nor engage in personal insults or ad hominem arguments, not even with parties who frankly deserved it. She has consistently gone out of her way to keep dialogue constructive, to treat people with respect, and wherever possible to find solutions that work for everyone, even in very difficult conversations. If Karen is unwilling to meet with someone without getting agreement on ground rules, there must be a very serious reason for that.

So when SFLC says âoethey have never once agreed to meet with usâ, I read that as âoeConservancy wasnâ(TM)t willing to waste time on a pointless face-to-face meeting on SFLCâ(TM)s home turf with no written agenda and with SFLC refusing to explicitly commit to basic ground rules of civil discourseâ. If I were running Conservancy, I would have made exactly the same decision."

FWIW, I wrote up a somewhat in-depth analysis of this SFLC / Conservancy dispute here: http://www.rants.org/2017/11/c...

TL;DR: Software Freedom Conservancy is behaving appropriately, and SFLC is not.

Even Xemacs that I often use, I've got one editing a html file and it uses 32 MB (and that's a low value, it's often 100MB). Why?

Newbies often get entangled in the vast pool of applications and editors. Let me enlighten you by linking to a piece of the bible made long time ago by very intelligent and experienced programmers; http://www.rants.org/ed.html

My recollection is that Zimbra has some very funky goings-ons in their licensing, and I'm not sure if "Freedom to Fork" is preserved in a reasonable way. (A license that forces derivatives to show their trademarked logo?) Therefore, I have never considered deploying Zimbra on the principle that in event of Zimbra's failure that a knowledge-vacuum would cause other firms to pick up the product.

Plus many of the modules that makes Zimbra actually useful are closed source.

For now I'd rather deploy Citadel ( http://www.citadel.org/ ) w/GroupDAV ( http://www.groupdav.org/ ). In particular its speed, turnkey-style administration, and replication options (thanks to BerkeleyDB) make it pretty attractive on the whole.

For more information, see
http://www.rants.org/2007/06/26/when-is-open-source-not-open-source/

Here is a more accessible opinion about XML.

What's your beef with the file format?

Part of it is just the usual: too verbose, the data gets lost in the formatting, as a human-readable format it fails miserably but human readability shaped its form considerably. I also find that not everything fits nicely into a tree structure, like XML wants. (This is partially shaped by my latest project, which requires more general graphs.) Now there's some things like XPointer and the like, which are the beginnings of pretty lame attempts to pretend that XML doesn't force everything into a tree.

The difference between attributes and elements isn't clear-cut, and providing both in such an arbitrary manner promotes confusion. Several people suggest good ways on when to use which, but it's silly to have a file format that apparently needs such recommendations to be repeated so many times. "Attributes are for metadata", the claim goes, "and elements are for data". I'll briefly ignore (as most such recommendations do) the fact that metadata may need to be structured as much as, or more than, data. My main point to this paragraph is that the distinction between data and metadata becomes blurred, particularly when you have different processors working on the same document. And isn't that what XML is for? If everything were clear-cut between attributes and metadata, we wouldn't have things like processing instructions (meta-meta-data?) and the like. Certainly, the xmlns attribute is on a different metalevel than some program's name attribute; why not draw a new metalevel distinction for that? Trying to draw a line between data and metadata like XML does a futile exercise. Everybody's metadata is somebody else's data, so just use namespaces or something instead of trying to make a distinction inherent to the file format.

Most people these days use object-oriented programming, and it's nice to be able to read in a file and have it generate an object tree of appropriate classes. But surprise! it doesn't work that way. The best time to do type assignment is during validation, and there's three main validation systems: DTDs, XML Schema, and Relax NG. DTDs are woefully inadequate in more ways than I can describe. Relax NG, while my favorite validation structure, doesn't assign type information to the data as it's validating because of the holy "Thou shalt not augment the infoset" mandate of Relax NG. Even though it has several constructs that just scream OOP subclassing, those constructs aren't visible to the user, just the parser. XML Schema puts type information into the infoset, so XPath etc can get at it. Other than that, once you get beyond the trivial, it sucks in just about every other way: it's not orthogonal, its extensibility and reuse constructs are as pathetic as anything I've ever seen, and it reeks of something that was built by passing a slapped-together application-specific spec into a committee after it's been pushed in several directions without any thought of graceful growth (which, of course, it was).

This is just what came to me quickly (although I've been wrestling with these issues for a while); I haven't stopped typing to think about what I'm typing. So I haven't carefully spelled out my issues, but that's okay; other people have issues too that you can read about. There's lots of places on the web to talk about the suckage of XML's file format. My personal favorites usually come from discussions among Lispers, because any Lisp programmer sees XML as sexps in drag.

Now that I've ranted about XML for a while, don't miss the point of my post (the GPP). XML brings some fine things to the table; I've spent the last year working heavily with XML by my own choice. But it's not a great file format. Many people see just the file format, and think that XML sucks. My point was to bring other aspects of XML to light, aspects that make XML a good thing overall.

And what's your propos