FYI: banshee in the 10/14 update

[GreyGeek]

I make it a deliberate point to keep MONO and its apps off of my Karmic.

Yesterday, while apt-get was scrolling through the dozens apps that it was installing I caught a brief glimps of banshee.

I never had previously installed banshee and after the update I discovered that banshee, mono-runtime and the libmono libraries had been installed.
I uninstalled mono-runtime and it pulled all dependent apps with it down the toilet.
Then I did an autoremove to catch the orphans.

Watch your downloads, folks! It looks like MONO is trying to sneak in the back door.

[kubicle]

Re: FYI: banshee in the 10/14 update

Do you use the default setting (in apt) of installing "recommends as dependencies"?

If you do, then my guess is that some package you were upgrading recommended banshee (or recommended a package that recommended banshee etc.), since not that many packages seem to actually depend on banshee.

[GreyGeek]

Re: FYI: banshee in the 10/14 update

Yes, I do, but I am not going to turn it off because for most apps I want the recommended co-installs.

I think what I will do from now on is to check for mono-runtime after each upgrade just to make sure "recommented" MONO stuff doesn't sneak by.

[doctordruidphd]

Re: FYI: banshee in the 10/14 update

I hope this isn't too naiive a question, but what's the issue with MONO? I have several applications that will get whacked if I remove mono-runtime.
Just a question, not looking to pour gasoline on any fires.

[GreyGeek]

Re: FYI: banshee in the 10/14 update

https://lists.ubuntu.com/archives/ub...ne/000584.html

Since the Mono stack is already a dependency of the default installation set for many remixes of Ubuntu, including the Desktop Edition, there is no reason to consider a dependency on Mono as an issue when suggesting applications for the default set.
...
Scott
on behalf of the Ubuntu Technical Board
--
Scott James Remnant
scott at ubuntu.com

There you have it. The Ubuntu Desktop Edition IS among the "remixes" of Ubuntu which have the MONO stack as a default dependency of the default installation set.

In the future I won't argue with anyone about the Ubuntu Desktop Edition being dependent on the MONO stack. I will merely point them to the MONO Position Statement by the Canonical (Ubuntu) Technical Board.

Attending the Technical Board on their June 30, 2009 meeting were three people:
* Matt Zimmerman (chair)
* Colin Watson
* Scott James Remnant

Mark Shuttlesworth was absent.

They considered 5 items of business, two of which were:

* Scott James Remnant has put forward a Technical Board position statement regarding Mono, which is to be published shortly

* The Technical Board is discussing the creation of a new governing body, the Developer Applications Board, to process new developer applications, separating this function from the Technical Board itself


The Technical Board bases its belief that Microsoft will not sue Canonical once Ubuntu becomes dependent on MONO on the following reasons:

1) The Ubuntu Technical Board has received no claims of infringement against the Mono stack, and is not aware of any such claims having been received by other similar projects.

2) It is common practice in the software industry to register patents as protection against litigation, rather than as an intent to litigate. Thus mere existence of a patent, without a claim of infringement, is not sufficient reason to warrant exclusion from the Ubuntu Project.

3) (While the Ubuntu project wishes to be responsive to patent infringement claims, we cannot commit to the assessment and review of claims made by anyone other than the registered rights holder.)


There you have both the declaration of the Ubuntu dependency on MONO and the reasons behind it.

Response to reason 1)
No official opinion from an IP lawyer? They are just going to sit and wait for the "Cease and Desist" order before they do anything? Who knows how long that will be? The longer they wait the more time, effort and Shuttlesworth's money they will have sunk into Ubuntu, and the greater will be the damage. The SCO lawsuit has been going on for about 6 years and is still NOT finished. SCO appears to be hoping for a "Hail Mary" from the Appeals Court. I predict that rather than waste his millions in a court battle Shuttlesworth will cut his losses and bail. Cutting MONO out of Ubuntu will set it back for as long, or longer than it took to embed MONO in Ubuntu.

Response to reason 2)
Knowing of an existing patent that your code violates but waiting for the patent holder to sue you before you'll consider removing it is insane. IANAL, but I understand that as long as Microsoft KNOWS about patent infringements but does not legally inform the infringer, describe the infringement, and give the infringer time to remove the infringement (not that removing it would remove fines and penalties), they lessen or remove their opportunity to collect fines and penalties if they later sue because it would be considered as "running up the fines", but that doesn't give the infringer a free pass to continue infringing.

Yes, I know about Microsoft's "promise". It won't be the first promise Microsoft has made and then subsequently broken, as many now non-existent startup owners can testify. Many assume that the ECMA completely covers every part of the .NET and C# technology in the MONO version of those components. It does not. Not even Microsoft's most recent "promise" clarifies that.


http://www.linuxtoday.com/news_story...-OP-CY-MS-0002

http://www.linuxtoday.com/news_story...-OP-MS-NV-0000

http://www.linuxtoday.com/news_story...-35-OS-CY-0002

http://www.linuxtoday.com/news_story...-35-OP-OO-0003

http://www.groklaw.net/article.php?s...71023002351958

Our mission is to establish Microsoft's platforms as the de facto standards throughout the computer industry. Our enemies are the vendors of platforms that compete with ours: Netscape, Sun, IBM, Oracle, Lotus, etc. The field of battle is the software industry. Success is measured in shipping applications. Every line of code that is written to our standards is a small victory; every line of code that is written to any other standard, is a small defeat. Total victory, for DRG, is the universal adoption of our standards by developers, as this is an important step towards total victory for Microsoft itself: "A computer on every desk and in every home, running Microsoft software."

Be sure to search that link for "slog" and "stacked panel". The whole document is an eye-opening read.


MONO depends on .NET and cannot advance ahead of it, therefore it must always be a version or more behind. Think of Skype 2 for Linux and Skype 4 for Windows. Not all of MONO is under ECMA 334 or 335, specifically the gui tools. So, MONO has to bind to the GTK2+ widget set to have gui interfaces. But, GTK+ doesn't need MONO. So, with MONO and $1.50 you can buy a cup of coffee.


http://www.linuxtoday.com/news_story...-35-OS-NV-0000

As far as MONO and MoonLight being on a Linux desktop, Microsoft's James Plamondon said it best: "Every application written to Microsoft's standards is a WIN for Microsoft..."

In other words, "He who controls the desktop API controls the desktop."

My question has always been: "What advantage for Linux and FOSS is there in giving Microsoft direct or indirect control of the Linux desktop?"

ABSOLUTELY NONE. To do so would result, eventually, in the destruction of Linux, a goal Microsoft has NEVER ceased to attain. So, why do certain people CONTINUE to campaign for MONO, even with hostility, in order to help Microsoft attain it's goal?

The rest of the article supports the inclusion of MONO/MoonLight by citing remarks from agencies and professionals who favor Windows and/or have a .NET product they'd love to sell on the Linux desktop because they KNOW that it's market share will only increase, unless Microsoft plans succeed.

[GreyGeek]

Re: FYI: banshee in the 10/14 update

http://www.linuxtoday.com/news_story...-OS-GN-MS-0009

Fighting for survival ....

It will be a sad state affairs if a Ubuntu has to compete against Microsoft using MICROSOFT'S OWN technology.

How would the North have won the war against the South if it had to use steel made by the South to make its weapons? How would the US have won against the AXIS powers if it used German or Japanese steel? How is America, or any other country, going to win against or match China in the economic battle if the only products on their store shelves are made in China?

The analogy of war isn't mine. It is James Plamondon's analogy. Plamondon may have had his TEs employ unethical, immoral and illegal tactics, but he was no fool. He realized that if an application was not written using a Microsoft API it was a defeat for Microsoft. So remember, every line of code written with an API controlled by Microsoft is a defeat for Linux. If Plamondon is smart enough to see that why can't you?

Linux CANNOT "outsource" it's language/development technology to tools derived from proprietary Microsoft technology and someday expect to defeat Microsoft on the desktop, or continue its success against Microsoft in the server room. The folks at Microsoft are smart enough to understand this. Why can't you?

[doctordruidphd]

Re: FYI: banshee in the 10/14 update

Hmm. Thanks for that info. I can do without f-spot and banshee.

When I brought up mono-runtime in synaptic, this is the information it provides:

Mono is a platform for running and developing applications based on the
ECMA/ISO Standards. Mono is an open source effort led by Novell.
Mono provides a complete CLR (Common Language Runtime) including compiler and
runtime, which can produce and execute CIL (Common Intermediate Language)
bytecode (aka assemblies), and a class library.

This package contains the Virtual Machine, JIT (Just-in-Time) and
AOT (Ahead-of-Time) code generator "mono".
"mono" executes applications for the CLI (Common Language Infrastructure).
Mono currently only supports the X86, PowerPC, ARM, SPARC, S/390, AMD64 and
IA64 architectures. Optionally this package configures BINFMT support.

Canonical provides critical updates for mono-runtime until April 2011.

Seems harmless enough. But maybe not. Thanks for the education; I didn't know the issues.

[GreyGeek]

Re: FYI: banshee in the 10/14 update

What the Synaptic info doesn't tell you is that NOT ALL of MONO is covered by the ECMA 334 & 335 "standards", as de Icaza and other pro-MONO folks implied.

It was revealed last July by Matt Asay, and others, that a group of MONO components, the "Microsoft-compatibility stack", including ADO.NET, ASP.NET, and Windows.Forms, among others, are NOT covered in ECMA 334 & 335 and thus any inclusion of MONO, with them, into a distro puts the developers and users of that distro in violation of MS patents that apply to the parts in MONO not in ECMA 334 & 335.

Icaza admitted this on his July 6, 2009 blog:

Astute readers will point out that Mono contains much more than the ECMA standards, and they will be correct.

In the next few months we will be working towards splitting the jumbo Mono source code that includes ECMA + A lot more into two separate source code distributions. One will be ECMA, the other will contain our implementation of ASP.NET, ADO.NET, Winforms and others.

However, he made the same claim in a June 10th, 2004 interview :

Regarding Mono and the Microsoft .NET patents, Ximian is now splitting the "non-free" parts of .NET in Mono, and so OS providers can decide if they want to include in their products the "non-free non-ECMA" portions or not. Apparently, even without the non-free portions, Mono is fully usable, complete with the GTK# bindings, database and other free parts.

So, if he really did it in 2004 why does he have to do it again? Was he just blowing smoke on the reporter in 2004, or is he blowing smoke on us now?

I do not use MONO or its apps because making a distro dependent on MONO is giving Microsoft control over the Linux desktop API because Microsoft controls .NET and de Icaza is copying .NET as the pattern for MONO. He calls what he does, in his April 2009 blog entry, "embracing and extending" .NET, as if doing that would eventually extinguish .NET and/or Microsoft.

Without the gui parts of the compatibility stack MONO has NO gui parts except the GTK# GUI API, bindings that allow MONO to use the GUI components of the GTK+ toolkit. That's why I say that with MONO and $1.50 you can buy a cup of coffee.

Consider .NET's monumental failure at the London Stock Exchange, which was touted by Microsoft, who used the "The Highly Reliable Time" ad to put a thumb in the eye of Linux, claiming they "beat out" Linux when, in fact, Linux wasn't even under consideration. A couple weeks ago the LSE announced that they bought a corporation which wrote and marketed a Linux stock market transaction solution that had been running reliably on other exchanges even before the .NET failure, and at 4 to 5 times the transaction speed claimed for the .NET solution. If MICROSOFT and it's partner can't create a mission critical app how can developers with NO access to the source code of Windows and .NET do any better?

Considering that de Icaza spent nearly 10 years working closely with Microsoft to develop MONO one can conclude that BOTH HE and Microsoft KNOWS what parts are covered and what are not. In fact, a report of the first MONO developers meeting in 2004:

Miguel and Novell legal staff are currently conducting a formal patent review of mono, and the team had already split up the components of mono into separate ECMA-based and non-ECMA components to clearly define what RedHat and others could make use of.

So, by the end of the spring of 2004 de Icaza KNEW about the patent risks in MONO and had ALREADY split out the offending code.

But a year later, in 2005, de Icaza said said

The new release of Mono is scheduled to improve upon Mono 1.0 in the following areas:

1. Windows.Forms API: This is part of the Microsoft-compatible stack. It is used by programmers on Windows to develop client applications with .NET. With Mono 1.2, we will allow people to bring their existing GUI applications to Linux.

By the fall of 2005 de Icaza was more concerned about splitting the WinForm parts because of code tree size , not patent concerns.

A year later, in September of 2006 the MONO team and the .NET team met at the LA Microsoft PDC:

...
At the meeting we will talk about the Mono Project's current state, milestones, new developments, platform support and upcoming releases. Various Mono developers will be there to answer your questions, both members of the community and Novell employees working on Mono.
...
We will answer your questions on how to bring your .NET applications to Linux, MacOS X and Solaris and how to take advantage of the Mono and Linux-specific APIs.
...
Finally, we will demo some of the the new Mono software funded by Google's Summer of Code:

* XBuild: the open source msbuild implementation for assisting you in rebuilding your new projects on Mono.
* Ruby.NET and PHP.NET compilers.
* The DIVA Movie editor.
* The new ASP.NET editor.
* The .NET bug finder.
* The Cecil libraries for reading and writing CIL images.
* Mono's XAML compiler.
...
Mono Birds-of-a-feathers (BOF)
...

NOTICE how de Icaza is using MONO to also embrace Ruby and PHP while trying to hijack the Linux desktop, and Google was paying for their work. I don't know if Google is still sponsering the work of their competitors.

Support for "BOF" was initially apposed by Microsoft but now they are fine with it.

These are mainly Microsoft coders who were being introduced to MONO so they can port their Windows .NET applications to Linux. To do that they need the "stack" or they have to re-write their GUI parts using the GTK# GUI API. The Linux coders are those working for Novell or are using commercial (paid, hence a royalty payment to Microsoft) versions of SUSE, which gives THEM immunity from MS lawsuits over using MONO. Most, if not ALL, of the pro-MONO folks are Windows developers wearing Tux suits who have invaded the Linux community and have declared that those who appose MONO are "faux" Linux community members and those who support MONO are "true" Linux community members. Essentially they are Windows coders looking for new markets for their shareware and applications. Getting distros to adopt Microsoft's API for the Linux desktop makes the Linux desktop a wholly owned subsidiary of Microsoft.

He who controls the Linux desktop API controls the Linux desktop.

There is NO question that Microsoft AND Icaza KNOW about the patent risks as well, and if so, it says volumes about their intent. Microsoft's "Promise" only applies to those parts of MONO that are in ECMA 334 & 335, which do not include the Windows.Forms API or other parts of the "Microsoft-compatibility stack". That stack is critical in getting .NET apps ported to Linux, or Linux MONO apps ported to Windows.

The MONO problem becomes serious IF Debian becomes DEPENDENT upon MONO, like Ubuntu has announced, because several distros spin off of Debian and they, too, would become dependent. distros which spin off of Ubuntu will have some considerations to do.

How to remove MONO patent concerns from your installation:

sudo apt-get remove --purge mono-common libmono0 mono libmono1.0-cil libmono2.0-cil

If, sometime in the near future, that command disables GNOME and / or Kubuntu then it would be time for me to find a different distro. It is my understanding that Fedora has adopted a policy of keeping MONO out of their distro.

[Snowhog]

Re: FYI: banshee in the 10/14 update

How to remove MONO patent concerns from your installation:

sudo apt-get remove --purge mono-common libmono0 mono libmono1.0-cil libmono2.0-cil

How will this affect the running system?

Add:
Well, on my Kubuntu Jaunty, I don't have to worry:

paul@laptop:~$ sudo apt-get remove --simulate mono-common libmono0 mono libmono1.0-cil libmono2.0-cil
[sudo] password for paul:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package mono-common is not installed, so not removed
Package libmono0 is not installed, so not removed
Package mono is not installed, so not removed
Package libmono1.0-cil is not installed, so not removed
Package libmono2.0-cil is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

[bastard_lunatic]

Re: FYI: banshee in the 10/14 update

I ran the sudo command GG offered and so far everything seems ok after rebooting. I got a "printer applet crashed" error message, which was kinda weird, Don't know if that has anything to do with anything or not though. I'm not quite as Linux saavy as the rest of you, but am learning.

[doctordruidphd]

Re: FYI: banshee in the 10/14 update

Thanks for the info. Given the nature of Microceph's business practices, it comes as no surprise that things are not what they appear to be.

sudo apt-get remove --purge mono-common libmono0 mono libmono1.0-cil libmono2.0-cil

Done. I still have a functional computer, in gnome and kde. No Banshee, of course. Maybe some day Amarok will learn to read CDs. Until then, there is Exaile.

[Snowhog]

Re: FYI: banshee in the 10/14 update

Maybe some day Amarok will learn to read CDs. Until then, there is Exaile.

See my [RESOLVED] Amarok 2 and audio CDs
I now have Amarok playing my music CDs - again. But, then, you are running Karmic, and Amarok 2.2, according to KDE, Amarok 2.2 ships with Karmic, and it does (again) play music CDs.

[GreyGeek]

Re: FYI: banshee in the 10/14 update

I ran the sudo command GG offered and so far everything seems ok after rebooting. I got a "printer applet crashed" error message, which was kinda weird, Don't know if that has anything to do with anything or not though. I'm not quite as Linux saavy as the rest of you, but am learning.

See lauchpad bug report 454626

It's a Python applet in the kdeutils package. It happens on both 32 and 64bit Kubuntu's. It must reload because my printer always works and it is connected via a wireless print server.

[GreyGeek]

Re: FYI: banshee in the 10/14 update

How to remove MONO patent concerns from your installation:

sudo apt-get remove --purge mono-common libmono0 mono libmono1.0-cil libmono2.0-cil
...
How will this affect the running system?

It won't do anything to either 32 or 64 bit Kubuntu Jaunty or Karmic except remove mono and mono dependent applications. Removing "mono-runtime" will have the same effect.

ADDED:
It is BECAUSE removing MONO totally from my Kubuntu installations does not cripple them that I will remain a Kubuntu user. I wasn't entirely sure when I first removed the mono-runtime. I had previously done a depends search on libmono.so and an apt-rdepends on serveral apps. I found 1,600 instances of dependencies on MONO in Kubuntu's repository, and removing the redundancies reduced the count to around 500. Some of them don't affect the main application but do affect some plugins. So, if you see an app like Audacity on the list that doesn't mean it won't run without MONO. It was written using the GTK+ tool kit and is an excellent example of why GTK doesn't need MONO but MONO needs GTK. The MONO developers have subclassed GTK widgets to create bindings to C# and MONO. Those bindings are referred to as GTKSharp (GTK#).

You can test an app to see what it depends upon by using:

sudo apt-rdepends appname

You will probably have to install apt-rdepends from the repository.

Even though you may have removed MONO from your Kubuntu installation it is still in your package cache. You can still use

sudo apt-rdepends mono-runtime

to see what it depends on, and why my MONO removal command works. Don't be alarmed if you see "dpkg" listed among those apps on which MONO depends. MONO depending on dpkg does NOT mean that dpkg depends upon MONO. When you see components of a distro that formerly did not depend upon MONO subsequently depending upon MONO you'll know that the MONO dependency policy will then be in full affect, and removing MONO will crash at least the desktop if not the kernel.

I attached my results to this msg.

[bastard_lunatic]

Re: FYI: banshee in the 10/14 update

I ran the sudo command GG offered and so far everything seems ok after rebooting. I got a "printer applet crashed" error message, which was kinda weird, Don't know if that has anything to do with anything or not though. I'm not quite as Linux saavy as the rest of you, but am learning.

See lauchpad bug report 454626

It's a Python applet in the kdeutils package. It happens on both 32 and 64bit Kubuntu's. It must reload because my printer always works and it is connected via a wireless print server.

Thank you GG! Fixed it! I appreciate you finding that for me.