No-Mono-by-Default

Differences between revisions 30 and 31
Revision 30 as of 2008-04-03 06:04:38
Size: 20915
Editor: c-24-14-126-238
Comment: Added a relevant comment for further community discussion.
Revision 31 as of 2008-04-03 06:06:15
Size: 20914
Editor: c-24-14-126-238
Comment: typo
Deletions are marked like this. Additions are marked like this.
Line 194: Line 194:
    * The fact that their are Novel's direct competitor, and that they purchased JBoss may have something to do with it.     * The fact that they are Novel's direct competitor, and that they purchased JBoss may have something to do with it.

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Update

gThumb has been removed instead of F-Spot which is the opposite position taken in this specification.

Summary

Remove Mono and dependent applications from default Ubuntu Desktop CD, because Mono by default is a bad strategic decision for Ubuntu and the essential functionality is provided by already included applications.

This will NOT remove Mono or any of the applications from the Ubuntu repositories, just the default Desktop CD. (Although removing them from the CD may mean they don't need to be in Main anymore)

Release Note

F-Spot and Tomboy Notes will not be on the default Ubuntu Desktop CD.

Users who currently have either installed will not have them removed.

Rationale

Ethical Reasoning

Beneficial To Competitor

  • Mono is implemented to be compatible with Microsoft's .NET instead of the standard.
  • Mono's compatibility requirement with .NET create a bad dependency on a competitor.
  • Providing Mono on the Default Ubuntu Desktop CD helps Mono become more popular as more people will use it by default.
  • By writing Free applications in Mono/.NET you put yourself at risk from Microsoft changing the .NET implementation creating more work for both Mono developers and application developers.

To Not Allow

"the era of 'open computing,' the free exchange of digital information that has defined the personal computer industry," to end.

Only getting binary codecs from Microsoft for Moonlight

Technical Reasoning

A lot of the functionality provided by Tomboy Notes and F-Spot are already included on the default CD by Sticky Notes and gThumb. Both Mono based applications use more than 4X the memory of their non-Mono equivalent.

F-Spot vs gThumb

Memory Usage* with the example content loaded

  • F-Spot: 20.0 Mb
  • gThumb: 4.9 Mb

Feature comparison
  • Both can do basic photo editing
  • Both have Metadata for photos
    • F-Spot was able to pick the metadata and present it faster, also tagging appears more prevalent in interface
    • gThumb can do categories, and view metadata, as well as comments
  • Both can import photos
  • Both can have a "Library" of your photos
    • gThumb gives you more control
    • F-Spot makes it more user friendly
  • F-Spot has a neat way to view photos by year
  • F-Spot has an easy slider to change the size of the collection of photos you are looking at
  • gThumb can handle Movies! It calls Totem to play them.

Overall, these applications are very much similar and including both of them does not make much sense. Having both could make some users confused as their functionality is so similar. I think the handling of movies by gThumb makes gThumb the winner in features. Most people who have a digital camera are going to eventually try the take a movie feature in it. Being able to easily import that into Ubuntu is very important for them.

TomBoy Notes vs Sticky Notes

Memory Usage* with no notes loaded

  • Tomboy: 19.2 Mb
  • Sticky: 4.4 Mb

Feature Comparison
  • Both allow you to take notes, hide them from view
  • Tomboy has notes appear as full windows
  • Sticky Notes appears as quasi-windows
  • Tomboy has note synchronization
  • Tomboy has export to HTML
  • Tomboy has Wiki-like linking in notes
  • Tomboy can do rich text formatting.

There is clearly some functionality missing from sticky notes that tomboy has. However Sticky Notes is designed to just be a simple note taking applet. Sticky Notes will NOT replace Tomboy for power users, who can always just install it later.

Assumptions

Mono/.NET being successful will not benefit free software.

Implementation

Remove dependencies from Ubuntu desktop package.

Migration

No migration needed, old installs will still be upgraded. Mono just won't be on the CD. Revert note taking app to already included Sticky Notes applet

It is important to note that people who already have Mono installed won't be affected. Even when they upgrade to the latest release; Mono, Tomboy, and F-Spot will still be upgraded with it.

Test/Demo Plan

Test to make sure removing Mono does not break other things in Gnome.

Notes

*Memory usage was tested using gnome-system-monitor which appears to have varied a good deal from one test to another, although I did change the pictures being used and notes. However, I still think it is valid enough to indicate that Mono based applications use more memory than their counterparts.

Comments

[http://ubuntuforums.org/showthread.php?t=634805]

PaulKishimoto: (Comments here because the forum thread is more ideological than practical) It may not be main-ready, but [http://www.conduit-project.org Conduit] could replicate Tomboy's synchronization and HTML export for Sticky Notes. SyncIntegration is a relevant UDS discussion linked from the Conduit homepage. Wikilinks in Sticky Notes and making gThumb as user-friendly as F-Spot would probably need upstream work; also note that Tomboy has some text formatting options while Sticky Notes AFAIK has none.

RobertKnight: (Note: I do not work on tomboy, mono or gnome, nor do I work for an affiliated company, but I am adding my two cents as a programmer and also as a user of the applications being discussed).

The arguments given in the 'Technical Reasons' section are lacking in good evidence. The memory figures are meaningless because there is no information about how the benchmarks were performed, exactly what the test data was and what the stated figure actually means - is it private, shared, rss, vmsize or something else? Despite what the basic system monitor tools that ship with gnome might tell you, there is no single figure that can be called "the memory usage" of a particular process. In other words, the figures given might as well be lottery numbers. I don't dispute the basic argument that a Mono application will use more memory than an identical application written in C/C++ but the question is whether that increased memory usage is an acceptable trade-off given the advantages that Mono provides to developers (whole categories of programming errors eliminated, potentially much cleaner code, less code) and indirectly to users (better applications arising from the benefits to developers).

Secondly, I strongly disagree that Sticky Notes could replace tomboy as a similarly useful application unless there were major changes in its functionality. Sticky Notes just provides pieces of plain text which can have names attached to them. Tomboy is a miniature hypertext system (in other words, it has the concept of links), which makes it an order of magnitude more useful. Not to mention that it does search, rich formatting, printing, HTML export, syncing and possibly many other things depending on the installed plugins. Some of these advanced features may not be useful to Ubuntu's target audience, but I would argue that the linking, search and rich text functionality certainly is.

In tomboy's case, the comments about Mono and "compatibility requirement with .NET create a bad dependency on a competitor" do not really apply. Tomboy uses only the basic system libraries (which provide collections, io, text manipulation, xml). The user interface is written using Mono's GTK bindings. GTK is obviously not part of .NET.

  • Is there a better way to measure memory usage? Sticky notes cannot replace Tomboy with those functional requirements however I don't feel that including Mono just for those extra features in Tomboy makes much sense. Both F-Spot and Tomboy have the 39.7 Mb dependency on Mono. Are you saying that Tomboy should have less, or does your argument apply to F-Spot as well?
    • Whether or not including Mono+F-Spot+Tomboy makes sense depends on whether something more useful to a general audience could be included on the CD if they were taken out. I'm not going to answer that. As for measuring memory usage, I took another look at gnome-system-monitor and it is more sophisticated than I thought. The "Memory" figure is actually quite a fair assessment, but it still doesn't tell you very much. If you enable the "Resident Memory", "Writeable Memory" and "Shared Memory" columns, those three figures provide much more useful information. If you right-click on the process and click "Memory Maps" you get a pretty detailed picture. This blog post (which happens to agree about F-Spot using too much memory) from last year gives an idea of what I mean: http://www.aigarius.com/blog/2006/07/31/spot-focus/ . It is worth noting that Mono has had a year's worth of development since then, and the latest release (1.2.6) is supposed to improve memory usage somewhat.

      • 1.2.6 still isn't in Hardy. But if it does land I will retest with it. As far as I can tell the Memory usage reported is the writeable plus X-server. gThumb and Sticky Notes both report a good amount of shared memory (13 and 8 respectively). As far as I can tell, shared memory is a "good" thing. The memory reported seems to be a fairly good test in my (IS not CS) opinion. Memory Maps are interesting, but a bit over my head right now. UPDATE: 1.2.6 just made it into hardy and I just quickly tested it on my desktop. It didn't change enough to warrant me to retest it on a liveCD. (Tomboy was at 15mb and F-Spot was 30ish)
  • I would highly appriciate that you make not only Mono packages but also packages to easily install dotGNU in Ubuntu, so I can introduce Ubuntu in our company who works on frontends build on .NET! Mono is to big, the legal issues are unclear and its not an option for us.
    • There is a dotGNU package in Ubuntu (it's called pnet).

RossPeoples: For starters, I just want to say that I don't develop in Mono, but its reasons for being included by default in the first place are still clear. Having said that, I don't think "possible legal issues" is a good reason to not include Mono. If you want to talk about possibilities, a mouse cursor "could" in fact, cause legal issues. OpenOffice "could" be a legal issue. Using Terminal "could" cause a huge meteor to destroy Earth. Besides, there are several large companies (Google, Novell, Sun) that have said they are willing to back the free software community if Microsoft were to claim patent infringement on Linux. And since Mono is backed by Novell anyways, you know they would put up a good fight if it were Mono-specific.

  • That is exactly the cause for worry. Novel is protected by MS-Novell deal. So they will not think twice before infringing MS patents. Also, Mono class libs are under MIT license. So there is absolutely no protection from patent suits even from developers of Mono.

As for memory usage, Mono only runs when you start an application that uses Mono. So, if you stayed away from Mono-based applications, then memory usage becomes a moot point. I agree with RobertKnight that Sticky Notes is no replacement for Tomboy. One of the features that makes it very useful for me is its syncing feature.

Your reasoning for "Microsoft changing the .NET implementation creating more work for both Mono developers and application developers" is also unfounded. Mono is written to suit the ECMA standard, not Microsoft's implementation. They do, however, include the System.Windows.Forms library as a compatibility layer only. Looking at the development of Mono suggests they are moving in their own direction, away from Microsoft. Your other reason, "helps Mono become more popular as more people will use it by default", should be considered a good thing. If it brings good developers and helps those developers use their Windows knowledge on the Linux platform, I'd say that's an accomplishment and leads to more and better applications.

In summary, it seems as though you just hate Mono and you want it removed for your own self-gratification. Using Mono, or any other framework/program/etc. is a preference. You have the option to NOT use it and to even uninstall it if you really hate it that much. But not giving end users the ability to run software they might already be accustomed to out-of-the-box is a huge leap backwards.

  • Please refrain from personal attacks. Please elaborate on the clear reasons for including F-Spot and Tomboy. I see note synchronization as an advanced feature that does not deserve an entire language for itself, especially on the default Ubuntu CD.

Markba: zim is an alternative for Tomboy. For starters, it does have wiki-style hyperlinks thus seems to be more feature complete then Sticky Notes. From the feature comparison between Tomboy and Sticky Notes:

  • Tomboy has note synchronization: (already mentioned) to be accomplished with conduit or any other generic sync framework (e.g. rsync, etc.)
  • Tomboy has export to HTML: zim includes this feature
  • Tomboy has Wiki-like linking in notes: zim includes this feature
  • Tomboy can do rich text formatting.: zim includes this feature

See: http://pardus-larus.student.utwente.nl/~pardus//projects/zim/

Alan: As a programmer who does use mono, i want to throw in my 2 cents. I also realise that because i admitted to using mono some people may immediately disregard everything i have to say, but i believe it helps to declare that.

* Possible Patent issues Every major piece of software has possible patent issues. Until there is evidence one way or the other as to what patents mono may infringe, it should be viewed the same as any other piece of major software - innocent until proven guilty. Also note that the mono team publicly claims that they will work around any patent issue by reengineering the code. Under Irish law (and maybe European law) this is legally binding statement when issued by the mono team.

  • I have removed the patent issue. -Bryan

* Memory Usage* with the example content loaded (F-Spot) It's quite possible that fspot uses more memory because it preloads images into memory whereas gthumb doesn't. That could also explain the performance advantage to Fspot. As memory used is still quite low in both cases, it's no reason to decide between them.

  • Maybe not with F-Spot vs gThumb, but for a note taking application, that's a ridiculous amount of memory.
    • * Yes, i agree. Tomboy does use more memory than might be expected. This might be worth raising
      • with the developers rather than ditching it for a less capable and/or less intuitive application.

* Feature comparison It's easy to look at a list of features and decide what application is better, unfortunately this is the worst possible way to compare software. The only way to compare software packages is to use both and figure out why is more intuitive. Which offers a better *user* experience. If i can burn a custom photo CD in fspot in 3 clicks but it takes 8 clicks in gthumb, then that's a win for fspot. However by your comparison, they would be equal.

As both applications are aimed at *organising photos*, i would benchmark the features based on the relevance to that task. Having the ability to execute an external application (which may or may not exist on the target system) isn't the killer feature you make it out to be. I personally never use Totem.

  • Do you use F-Spot or gThumb?
    • * Yes, i use Fspot. I used gThumb once or thrice, but i preferred fspot as i said below. - Alan

* Whether the applications should be switched The only reason i see to change a default application is if the new application offers either a better user experience in the common tasks the application is targeted at, or it offers more *useful* features based on the target usergroup, or some other distinct advantages over the existing default. I don't see gthumb offering those, and (personally speaking again) i've used fspot since before i ever became involved in C#, i prefer it's interface. It's prettier and intuitive.

  • As the update I just added, gThumb is being removed (and F-Spot appears to be staying)

Alan: Only getting binary codecs from Microsoft for Moonlight Firstly, Mono has no dependency on moonlight. So that makes it's inclusion here irrelevenat. Also (I'm not 100% sure on this), i believe Moonlight (when released) will rely on an internally bundled mono runtime and so won't even have a dependency on mono. That needs to be checked though. Either way, Moonlights existence has no bearing on either Fspot or Tomboy or Mono. Also, if you were so worried about bundled binaries, I hope you don't use or need binary blobs for your wireless card or graphics card. But this is a separate discussion and if you want to discuss Moonlight inclusion, we need a separate wiki page.

  • Moonlight is using a subset of the mono runtime. You are correct in saying that moonlight has no bearing on F-Spot or Tomboy, but it definitely has a bearing on Mono. By including Mono we are positioning ourselves to easily be able to include Moonlight by default (it would be trivial to include as it is a subset).
    • * Moonlight will not use a system installed version of mono. It will use it's own bundled mono. Whether you have
      • mono installed or not, you can still install and run moonlight. This can be verified with the mono developers i assume, i can't find explicit documentation on this as moonlight hasnt been released officially yet - Alan.
    • "By including Mono we are positioning ourselves to easily be able to include Moonlight by default". That's the same to say that including Linux we are positioning ourselves to easily be able to include Oracle by default (because Oracle runs on Linux). Or that you shouldn't buy a knife because that way you are positioning yourself to easily be able to kill your wife in the middle of the night.

Alan: I seem to have lost my last comment, let me write it again except more briefly.

  • Mono is implemented to be compatible with Microsoft's .NET instead of the standard.

Mono is compatible with the ECMA specification, you imply it's not. I think this point is invalid and should be removed. Mono also aims to be compatible with MS.NET, but not when that clashes with spec compliance. This could be better clarified by mono developers.

  • Providing Mono on the Default Ubuntu Desktop CD helps Mono become more popular as more people will use it by default.

I don't see an issue here. Having people use mono is neither good or bad unto itself. It is just a fact. If people use mono, it becomes popular. This is only an issue if mono itself is 'Bad'. As mono is not 'Bad' unto itself, except in personal opinion, this point doesn't make sense.

  • By writing Free applications in Mono/.NET you put yourself at risk from Microsoft changing the .NET implementation creating more work for both Mono developers and application developers.

If microsoft break spec compliance, that won't affect mono being spec compliant. All your code will still run fine, even if microsoft completely butcher their runtime. Of course, if they did that they'd also lose all their existing business customers. This isn't an issue.

Do we know why Redhat wont endorse MONO, and is that applicable to ubuntu at all ?

  • The fact that they are Novel's direct competitor, and that they purchased JBoss may have something to do with it.

I also think that: https://bugs.launchpad.net/f-spot/+bug/34074 < having a current open bug and no further reply to a launchpad members concerns should be addressed at the very least, and needs to be dealt with if indeed f-spot is to be considered for being default image viewer.

  • Apart from the fact that that bug is a feature request (that could be filed against 99% of the software used today, btw), it has indeed been replied. Lots of other bugs receive similar attention and thus would position a lot of other packages in the same place.


What about the users?

I believe that removing Mono and applications that our users have become accustomed to would be a mistake. It is already difficult to convince individuals to switch to Linux. What do you think will happen when a novice installs a new version and discovers that all the familiar applications are missing? Let us not forget that we are striving to be the most user-friendly desktop distribution.

No-Mono-by-Default (last edited 2008-10-29 17:40:45 by c-24-0-106-77)