After all the debate, gtk# will most likely find its way into GNOME. “The release team has completed its second meeting to try to finish the new module decisions. And, after all the long threads on d-d-l and the many discussions amongst ourselves trying to determine community consensus, we finally have the decisions. In summary: orca, alacarte, and gnome-power-manager are in; gtk# and tomboy are in, assuming the issues mentioned are resolved; sticky notes becomes deprecated, assuming tomboy issues are resolved and gets in.” Update: Elijah Newren emailed me concerning an important aspect of the current decision, and asked me to highlight it. So, read more!Elijah asked me to highlight the following part of the decision concerning gtk#:
“New modules may be accepted into the desktop or admin releases with a dependency on gtk#/mono, but any modules accepted into either of those release sets without a dependency on gtk#/mono may not gain one without going through the proposal process again in a subsequent release.”
Eliah explained:
“The ‘but’ clause appears to have missed several peoples’ attention, but I believe it was critical in making this decision palatable to those who strongly opposed any dependency on gtk# (it effectively is an assurance that those who want to remove gtk# will be able to do so without crippling their Gnome installation). I have received at least one email (from the person who I thought was most strongly opposing such a dependency) to that effect. Anyway, I fear that without this rule accompanying the article, people will draw the wrong conclusions about this decision — causing more effort wasted on unnecessary flamage rather than be put to good use on pushing the free/open source desktop forward. That may be an unfounded fear, but it’s one I have nevertheless. ;-)”
Through experience, I think that that fear is anything but unfounded.
I’m glad to see that the political and anti-MS issues didn’t prevent mono from becoming part of the gnome desktop. I’m also glad gnome-power-manager made it in as it is absolutely the best user power management tool for the Linux desktop.
I’m glad to see that the political and anti-MS issues didn’t prevent mono from becoming part of the gnome desktop
Can you explain how the threat of MS litigation is an anti-MS issue please ?
Legal threats are not fantasies like you think, you don’t have to be anti anything to acknowledge their existence.
I’m also glad gnome-power-manager made it in as it is absolutely the best user power management tool for the Linux desktop
You mean for the Gnome desktop. And even if it wasn’t in Gnome, nothing prevented you to put it in your Gnome desktop before, as I’ve done.
Talking about that app, I don’t see any sign of the notification API …
Can you explain how the threat of MS litigation is an anti-MS issue please?
For one thing, Microsoft hasn’t actually threatened a lawsuit against Mono. They’ve had very little to say about Mono, one way or the other, actually.
For another, the liklihood of Microsoft suing Mono is low, historically, as Microsoft is typically the defendant of lawsuits, not the plaintiff. (Search for STAC, Internet Explorer, SQL Server…)
Of course, past behavior is not a predictor for future behavior, just like the stock market.
Finally, nothing stops Microsoft from suing everything else in Linux, from the Linux kernel (http://www.networkworld.com/news/2004/0802linuxstu.html) to Samba to Wine to Python to Gnome to…
That’s what makes patents so damaging, they can be used to target everything. Plus, lawsuits are freaking expensive, so even if there’s no case they can still be damaging…
Then there’s the non-Microsoft patent holders — do you think FireFox is permanently exempt from the ‘no embedding items’ patent? Or the patents of search engines? Or the patents on XOR? JPEG? …
And do you think Sun’s Java is any better? Remember the lawsuit they lost against Kodak? (http://news.com.com/Sun+settles+Kodaks+Java+suit+for+92+million/210…)
What’s to stop Kodak from suing GCJ, Mono, Python, or anything that makes use of an RPC-like mechanism?
In short, patents are a problem for everyone; Mono isn’t a special target in this regard.
So the “threat of a Microsoft lawsuit” is anti-Microsoft because it’s short-sighted. Microsoft may bring a lawsuit in the future; they may not. But assuming that they’re the only source of lawsuits is wrong, and leads to thinking like “Mono is the only unsafe technology, and we’ll all be safer sticking with C, Java, Python, Perl, Ruby…” which, as shown above, is wrong.
Make sure you see the forest (patents covering everything) for the trees (a currently non-existant threat from Microsoft).
No, the threat of a Microsoft lawsuit is not Anti-Microsoft because the Mono folks did implement ADO.NET and ASP.NET even though they knew these technologies were patented.
If Mono did not reimplement the patented parts, Mono would be much safer and the community would not have strong arguments against it.
Saying that this attiude is anti-Microsoft because other implementations of patented stuff is not mentioned is not valid.
However, it is true that people have a tendency to cite the patents issue more when Mono is involved that when Python is involved. This is double standards at work.
No, the threat of a Microsoft lawsuit is not Anti-Microsoft because the Mono folks did implement ADO.NET and ASP.NET even though they knew these technologies were patented.
I’m a contributor to Mono.
I’m not a patent lawyer (but I did sleep at a Holiday Inn last night! ;-).
I haven’t heard anything about actual patents on ADO.NET and ASP.NET. I’ve only heard about the (rediculous) patent application (still not granted) about the design and structure of a class library (too lazy to Google the reference, but everyone had a good laugh at it; it’s like trying to patent a VCR interface, rather silly).
Furthermore, patents usually cover implementation, not the public interface. (Though its entirely possible that the public interface may require a particular patented implementation…)
Regardless, not supporting ADO.NET, ASP.NET, and System.Windows.Forms would be a huge mistake. One of the “selling points” of Mono is that code can be easily shared between Linux & .NET. Porting will be required, but (hopefully) such porting would be minimal. ADO.NET and ASP.NET help make that possible.
Without their support, it would require that “porting” be “re-write to this entirely different framework.” (See how well the “Abandon System.Windows.Forms and port your existing code to Gtk#” mantra is working for non-Free software.) In short, porting would no longer be an option, removing most of the appeal of Mono to third party vendors.
So given a choice between hand-waving about potential Microsoft patent threats vs. making it substantially easier for existing .NET code to be ported to Mono… What would you choose? You can always avoid ASP.NET, ADO.NET, and System.Windows.Forms for your own code…
Also to me it seems like Mono is becomeing the leader of GNOME. I’m not saying that’s bad or good I just find it funny with all the fury from GNOME at MS in the past. Is MS not that bad anymore?
It would be at least five years before this happened, but I think it would be cool if the entire DE was Mono based. I know that would make things easier for me. I run 64bit linux and with mono apps I don’t have to have compat 32bit libraries (well at least not as many). Maintainers wouldn’t need as much arch specific stuff to maintain if they were using mono heavily.
Edited 2006-08-02 14:18
Mono is very nascent. Give it some time before something drastic like that is done.
Yes it would be cool if the entire DE was Mono based.
Rapid and more easy development is very nice but..
Alas, not only Linux uses GNOME. Mono only runs decent on Windows and Linux, would you leave out all those *BSD, AIX or whatever architecture people? That woudn’t be very nice.
Maybe for gnome 4.0 or 5.0 when Mono does run good on those platforms.
There are more limitations like that. So, although the idea of having it all run on Mono might be an intresting one, it won’t allow everyone to the party anytime soon.
It IS possible to dislike MS business practices but be able to recognize something they did right. .NET is one of those things done right.
Disliking everything they do simply because THEY did it is ignorant.
Fantastic post Jon, thanks for taking the time to write it up.
.NET is an ECMA standard. In being a public standard, Microsoft can not “sue” anyone for using / implementing it (Read NOVELL for mono). They can potentially sue someone for using their own technologies (read ASP.NET which mono does ship) which are not public standards. However, ASP.NET and Windows.Forms support can be removed from mono as the code is pretty well done and modular.
Also, thanks the to patent commons, lawsuits like such from MS would become frivilous and thrown out of court. My best friend is a patent lawyer and we spoke about this
.NET is an ECMA standard. In being a public standard, Microsoft can not “sue” anyone for using / implementing it (Read NOVELL for mono).
Yes, they can. I explained this some time ago, and how the ECMA stuff is patentable. Remember that the ECMA specifies practically nothing to get working .Net implementation:
http://www.osnews.com/permalink.php?news_id=15266&comment_id=145802
The flimsy ECMA grant only gives people a RAND agreement to use those standards for a period of time. However, what it does not do it stop somebody from holding patents and licensing them.
They can potentially sue someone for using their own technologies (read ASP.NET which mono does ship) which are not public standards.
That’s just one of the common misconceptions perpetuated by the Mono people. It’s wrong.
However, ASP.NET and Windows.Forms support can be removed from mono as the code is pretty well done and modular.
That would be really useful wouldn’t it? And it wouldn’t change a thing.
Also, thanks the to patent commons, lawsuits like such from MS would become frivilous and thrown out of court.
No. In the case of .Net Microsoft has some patents that apply specifically to .Net, the CLI and other parts of it. Similar concepts implemented in different ways (java etc.) are actually absolutely fine. Microsoft want to protect what they see as their property.
Can you explain how the threat of MS litigation is an anti-MS issue please ?
Legal threats are not fantasies like you think, you don’t have to be anti anything to acknowledge their existence.
Sure, it doesn’t exist. RedHat, who was saying it did for the longest time, finally admitted that there was no real issue with the mono core. There MAY be issues with Windows.Forms and other select components that aren’t directly part of .NET, but those are already abstracted and if a legal issue arises, its very simple to get them out. Remember, .NET is a ECMA standard submitted by Microsoft, so they won’t get very far saying Mono can’t implement .NET or C#.
You mean for the Gnome desktop. And even if it wasn’t in Gnome, nothing prevented you to put it in your Gnome desktop before, as I’ve done.
Talking about that app, I don’t see any sign of the notification API …
But widespread adaption and integration with all of the other desktop components is extremely important for a complete desktop. And I mean Linux desktop. KDE, XFCE, and the other desktops power management solutions do not compare to gnome-power-manager IMO. Of course, you are free to disagree, but my opinion relates to the Linux desktop as a whole, not limited to just Gnome.
Sure, it doesn’t exist. RedHat, who was saying it did for the longest time, finally admitted that there was no real issue with the mono core. There MAY be issues with Windows.Forms and other select components that aren’t directly part of .NET, but those are already abstracted and if a legal issue arises, its very simple to get them out. Remember, .NET is a ECMA standard submitted by Microsoft, so they won’t get very far saying Mono can’t implement .NET or C#.
And given the EU ruling on the provision of specifications to third parties to allow better interoperability and compatibility, I doubt Microsoft is going to risk rocking the boat anytime soon.
At the end of the day, I think, there are many parts which aren’t going to be implemented (Indigo, Avalon, XAML) simply because the Novell/OpenSource developers feel that they can provide a better alternative to the Microsoft designed technology; case in point, use GTK# rather than Winforms – GTK# being the preferred widget kit and Winforms being there mainly for compatibility reasons rather than being a ‘core component’ that developers should rely on.
Edited 2006-08-02 19:03
At the end of the day, I think, there are many parts which aren’t going to be implemented (Indigo, Avalon, XAML) simply because the Novell/OpenSource developers feel that they can provide a better alternative to the Microsoft designed technology; case in point, use GTK# rather than Winforms – GTK# being the preferred widget kit and Winforms being there mainly for compatibility reasons rather than being a ‘core component’ that developers should rely on.
Where is this blind trust of Microsoft coming from when they aren’t open sourcing .NET like Sun is with Java? Is there some sort of ‘middle ground’ GNOME developers are supposed to except now; where they have to cater to the big guys? Is it even legal to be copying directly from .NET? I know with Java when it was closed, Java ports were considered not Java but completely different languages as was stated on those websites. Eventually MS will have no choice but to seek royalties with Mono as they do with .NET.
Hi,
well I can’t believe it
But not in a negative way! I had never believed, that the gnome team would accept gtk# or gnome# in gnome.
Personally I am neither for nor against gtk# in gnome. Because if I wanna have a gtk# application on my computer I can simply install mono and gtk# and can use the application without any problems.
With gtk# in gnome I think we will have some more mono based apps in gnome. If it is good, or bad… sorry, but we all don’t know it
So nobody can say, what the future brings, let’s see.
I simply hope, that nobody of the gnome developers overreacts in any way now, because of this decision.
What I don’t understand – maybe some of you can help me:
” => disappointment expressed about gtk# bindings to gnome-vfs not
being in the bindings suite, but the issue not considered a
blocker”
Do I understand it right, that gtk# will become a binding without gnome-vfs? Is gnome-vfs in gtk# or is there a #gnome-vfs binding? And why can’t there be a gnome-vfs binding for gtk#? Maybe my english isn’t good enough.
Most interesting in my opinion is the fact, that the gnome-power-manager is part of gnome now. It is really amazing work and in my distribution I had some issues to get this application working. It is an application I’ve missed in the gnome desktop for a long time. (Since I use gnome and have notebook
) So I am really happy and I hope this will lead to an easier installation of this programm.
Greetings
Mike
I am very glad that gnome team make this decision.
This has been a pretty surprising year. First XGL, now AIGLX in 7.1 leaving no excuse for Kwin or Metacity to not take advantage of either. I believe Metacity has already moved forward.
And now Mono & GTK# / GNOME#. I honestly thought it would be impossible for them to agree (on anything) and move forward.
Whose going to clean the mess the pigs left on my car?
I think gtk# in gnome is a good thing.
But RetHat has previously stated that they was not intrested in gtk# in gnome. Do this mean a gnome fork is around the corner?
Please read the full announcement.
Also, Red Hat is already shipping Mono and gtk#.
Redhat does not ship Mono Fedora does. Redhat has already made a statement that while Mono was going into Fedora there were no plans to include it Redhat.
I wonder what Redhat will do when Mono becomes part of Gnome?
Red Hat ships Fedora, Fedora ships Mono. You do the rest.
Red Hat has already mentioned they’ll use f-spot and beagle for RHEL 5.
Distros don’t have to ship packages even if the GNOME organziation names them “official”. Case in point: Ubuntu ships Firefox has the default browser, not the official web browser Epiphany.
I don’t want to start a flame war but I have something to say about it.
It’s a bad decision. Not because Mono sucks. Not because the binding sucks. Not at all. But because it requires way too much ressources.
Let’s face the truth. Ubuntu 6.06 (Gnome) is barely usable on this Celeron 500 with 256mb of RAM. It feels so slow. But this computer isn’t that old. It’s still a 500mhz with 256mb of RAM. Any desktop OS should run perfectly on it. XP does. And what about the One Laptop Per Child project? Are they going to give some brand new Core Duo to the kids?
But that’s not a reason to not include Mono for now. But it will be the day that some core parts of Gnome will depend on it. gnome-power-manager for example. If it becomes a core piece of Gnome then we will have a problem. People with older laptops won’t be able to use Gnome anymore? Just for fun, go read the sys req for SLED. The recommend a 2ghz CPU + 1gig of RAM. It’s nonsense.
I hope that developers will consider this. I know it’s sometimes much faster to write managed code. But if you target audience is 50% smaller, you’ve got a big problem.
Let’s face the truth. Ubuntu 6.06 (Gnome) is barely usable on this Celeron 500 with 256mb of RAM. It feels so slow. But this computer isn’t that old. It’s still a 500mhz with 256mb of RAM. Any desktop OS should run perfectly on it. XP does. And what about the One Laptop Per Child project? Are they going to give some brand new Core Duo to the kids?
OLPC obviously has far different resource requirements that would disqualify many applications and certain things already. So that is irrelevant to the current discussion.
As far as 256mb of ram and XP running fine? Hah! Only if you’re running one program at a time maybe. I work on a XP Professional box with 512mb of ram every day, and sometimes it absolutely craws while Windows swaps out memory. All I need is Outlook, a few terminal windows, and Internet Explorer loaded and I can get it to churn pretty badly.
We’ve left the days of low resource systems long behind, and I don’t miss them. Quite frankly, it is idealistic at best to believe that a modern desktop with all of the functionality, “eye candy,” and everything else users demand can fit into such a small amount of memory and still be useable with multiple applications running.
I won’t even go into the resource requirement increases that unicode support has forced upon us, but that’s the price of supporting internationalisation. I also don’t believe in the “bloat” argument I hear thrown around way too often. One person’s bloat is another person’s absolutely-must-have feature.
“Let’s face the truth. Ubuntu 6.06 (Gnome) is barely usable on this Celeron 500 with 256mb of RAM. It feels so slow. But this computer isn’t that old. It’s still a 500mhz with 256mb of RAM.”
Well, I’m sorry to tell you that your computer is “that old”. Celeron 500 was released in 1999, 7 years ago, and was based on an architecture that was more than 1 year old at the time. 7 years is also the interval between your Celeron and the last 80386.
No to mention that Celeron was already a weak processor at time it was bought. All this talking will finally end when Vista is released. Requirements like 2GHz processor and 2GB Ram to get things done will be a cold shower for some I guess.
Don’t expect to run 2006 game on 2000 computer.
Time flies, don’t it? 2 GHz CPUs are at this point 5 years old (Intel released their 2 GHz P4 this month in 2001). For comparison, the SOTA CPU 5 years before that, in 1996, was the Pentium Pro at a blistering 200 MHz.
Let’s face the truth. Ubuntu 6.06 (Gnome) is barely usable on this Celeron 500 with 256mb of RAM. It feels so slow.
I had a desktop with the same spec a few years ago. I seem to remember it feeling slow even then, with Windows 98. Those old Celerons really are terrible, I’m afraid.
Anyway, have you considered Xfce?
But it will be the day that some core parts of Gnome will depend on it. gnome-power-manager for example.
gnome-power-manager is written in C/GObject. Why would they change to C#?
Edited 2006-08-02 09:36
As others have pointed out, your computer is 7 years old, but more importantly, these design decisions will affect upcoming releases of gnome, to run on upcoming distributions. I’m sure a release of gnome 5 years ago would have been plenty fast enough on your computer. Vista certainly wont be, and neither would mac os x (anti-piracy restrictions asside) be. Linux is no different. Don’t compare gnome today with operating systems 5 years old its no surprise they run differently.
>Let’s face the truth.
Here we go.
>Ubuntu 6.06 (Gnome) is barely usable on this Celeron 500
>with 256mb of RAM. It feels so slow. But this computer
>isn’t that old. It’s still a 500mhz with 256mb of RAM.
Am using Ubuntu 6.06 (GNOME) here on a 400MHz with 192MB and it is fine.
It is snappier than my XP box which four times as much of everything – which is why I use it more! If I open a number of windows the swapping starts but, hey, we knew that anyway.
This is installed from the “alternate” ISO which states itself to be intended for machines with less memory.
no, we are not going to hold up progress for people driving model Ts. go download fluxbox and stop insisting the world move back to the 90s.
One Laptop Per Child project? Are they going to give some brand new Core Duo to the kids?
But that’s not a reason to not include Mono for now. But it will be the day that some core parts of Gnome will depend on it. gnome-power-manager for example. If it becomes a core piece of Gnome then we will have a problem. People with older laptops won’t be able to use Gnome anymore? Just for fun, go read the sys req for SLED. The recommend a 2ghz CPU + 1gig of RAM. It’s nonsense.
I am curious to what the difference is between GNOME, KDE and XFC in terms of resource use post Mono inclusion. Steven Vaughan Nicholes from http://www.desktoplinux.com uses SLED as his primary OS and prefers the KDE desktop with it, as reviewed. He didn’t seem to have any problems.
I wouldn’t worry about the OLPC program as they can use a more .lightweight desktop, if necessary, with really no hitches. If GNOME gets too bulky Negroponte will really start to hate it as he is fanatical about speed optimization.. It’s just a matter of a simple repo update from the client. He also removed the CPAPS LOCK. 4 countries just ordered 4 million of them.
1) Will turn into GNOME v KDE flamewar
2) Will become a mono is a legal nightmare thread
3) Will get distracted into tomboy is useless I prefer screen and 17 virtual terminals
4) Will turn into a python vs mono flamewar
5) Someone will pull the resource hog VM card
6) Someone will mention java as a better alternative
7) Someone will use their experience with one mono app as representative of the quality of all mono apps
8) Someone will wildly claim that in 3 months time the entire GNOME stack will be written in C# and then we will all get sued
9) Someone will be disappointed in Miguel and say he is now a corporate shill
You all will forget that we are not the average computer user.
Most of us will be burnt out in 5 years time. It is the kids learing C# now that will write the free desktop of the future. Is mono a productive tool for that job? ABSOLUTELY
I seriously hope I’m not burnt out in 5 years time… My generation of American software engineers won’t be able to retire until we’re at least 75 years old (if we’re out of debt by that time), and I’m only 23. I’ve got to put in another 52 solid years of development before the meager social programs in my country (if they still exist…) can support me.
And when China decides to call in the multi-trillion-dollar tab we’ve got going, and the neo-conservatives decide to pay it out from the 401Ks of the politically powerless middle-class, I’ll be doubly screwed.
So don’t talk to me about getting burnt out. I simply can’t afford to stop programming. Ever.
I recently tried to install mono, and I got the following error: No rule to make target `System.Runtime.InteropServices/SetWin32ContextInIDispatchAttribute.cs ‘. Apart from the solution of the problem, I find it very dissapointing that I have a fatal problem that seems to be some kind of interoperability aspect of *windows*. Enough things in the source tarball refer to that platform anyway, so it seems. After succesfull compilation, I seem to end up with a directory full of .dll’s and .exe files, apperently.
I double checked wheter the tarball i downloaded was named ‘mono’, and not ‘wine’ or something. Yes, i know both projects are not comparable, but i coudn’t suppress the nightmares i had from the times i ran a windows operating system. Subjective ofcourse, but nontheless disappointing, at least for me.
Mono or .NET or C# may be good as a language, but I can’t sleep well when I’m thinking about to have .dlls or .exes on my Linux box for Linux programs. Feels kinda weird.
Tom
Hmmm… i sort of understand, but what is different between .exe and an executable .sh or .py for that matter … nothing really, apart from the ending.
Mono or .NET or C# may be good as a language, but I can’t sleep well when I’m thinking about to have .dlls or .exes on my Linux box for Linux programs. Feels kinda weird.
Why? It’s little more than a different file extension and file format. You could name all your Linux programs with .exe and they will still work just fine
Why? It’s little more than a different file extension and file format. You could name all your Linux programs with .exe and they will still work just fine
I often reason that Mono/.NET (and also JAVA) is not cross platform. it IS a platform, with its own binaries, library formats and so on, and it has to run on specific (host) platforms. Access to system resources and other libraries happen via wrapping. Gtk#, for instance, is not a toolkit itself, it is a wrapper around Gtk+, the actual toolkit that makes use of X and it is targeted primary for providing X functionality.
One can ask why one would want to introduce a different file extension and file format, formats from a totally different platform, to another system. In this case, a platform originally designed for Windows, by Microsoft.. I think this is the case here. If this succeeds, then we’ll end up with a system based on different technology rather than the UNIX technology as a basis, right on top of that UNIX system. Whether that is desirable or not, depends on how you look at the situation. But introducing such a new platform on top of the standard Linux system compared to running a windows program in Wine actually give me the same feelings, personally. If you know what i mean.
I’d rather choose a scripting or JIT language that is more tied to the UNIX core system, than an wanna-be abstract system like Mono (or JAVA). I use the word ‘wanne-be’ explicitly, since I feel that the appearance of the Mono system (.dll’s, .exe’s, specific class functionality for win32, windows forms and stuff) is tied directly to the Windows platform.
Edited 2006-08-02 15:17
Damn I like stickynotes, please leave them in GNOME as tomboy sucks and is bloated compared to them.
Let me help you understand. Tomboy is fancy. Tomboy is sticky notes on the desktop taken to the next level. Tomboy is high-tech, it uses Mono, which is modern, not like old-fashioned C. Tomboy gives you all you need: make-up of the note, spell-checking, Wiki links between notes, plugins (another fancy feature!). In short, Tomboy has “fancy” written all over it….. how in the world can you prefer “sticky notes”, a very simple application which let’s you do only.. plain sticky notes?
Let me tell you I feel exactly the same like you. I’ve used Tomboy for a while some time ago and I didn’t like it at all. Sticky notes is just perfect for me. No fancy stuff at all, just plain simple sticky notes on your desktop.
I think it’s sad that Sticky notes is deprecated. If this is a sign of what the future is holding for the Gnome desktop, then it’s even more sad. It seems like every application needs to be fancy and needs to be glowing from all the “high-tech” in it and the plain simple applications need to go.
It seems like every application needs to be fancy and needs to be glowing from all the “high-tech” in it and the plain simple applications need to go.
I keep hearing the complete opposite things from people. Earlier today someone was complaining that they hate how gnome’s philosophy is keeping things way too simple and no fancy applications and removing features everywhere.
I think they’re doing a great job.
Gtk#/Gnome# inclusion was inevitable. It is a decision driven by the available applications.
Regardless of your stance on the ethics and legal ramifications of adopting Mono, it can not be denied that several best-in-class applications are emerging that are developed on Mono. They showcase Mono not just as a viable application development platform, but even moreso one that increases productivity and facilitates the creation of quality programs.
Look at Beagle, F-Spot, Banshee, Tomboy. Then there’s the development environment MonoDevelop. People push Python but where are the showcase Gtk/Python applications? What RAD tools does Gtk/Python have?
Mono is based on ECMA standards, there is no legal ambiguity. There is nothing Microsoft can do to pull Mono down in a court of law, the lines are drawn and the law is clear. There is enough corporate push behind Mono to fend off any potential attrition lawsuits. So not only is Mono legally sound, it is also capable of defending itself.
At the end of the day users care about one thing; the programs they use. If users use Mono applications then including Gtk#/Mono as part of the Gnome desktop is the only logical direction. You can’t ignore your users.
Mono is based on ECMA standards, there is no legal ambiguity. There is nothing Microsoft can do to pull Mono down in a court of law, the lines are drawn and the law is clear. There is enough corporate push behind Mono to fend off any potential attrition lawsuits. So not only is Mono legally sound, it is also capable of defending itself.
I like Mono, but there are problems using it. The database layer is using ADO.NET which is patented and so Novell can be sued if Microsoft wants.
This is a problem nobody can deny. See http://www.mono-project.com/FAQ:_Licensing
It means that if Novell gets sued Mono programs most likely will need to be rewritten using a new database API. I cannot really see how they keep the ADO.NET API.
People push Python but where are the showcase Gtk/Python applications?
It’s early days, but Jokosher looks excellent. Also, Quod Libet demonstrates that it’s possible to use PyGtk for large apps (although I personally use Banshee).
What RAD tools does Gtk/Python have?
Python really does need a decent IDE, I quite agree.
I have Quod Libet and Listen (both Gtk/Python apps) on my computer, and they do struggle with large databases. For small databases, they probably do not cross over the threshold beond which their lack of speed is noticeable, but I might have crossed that threshold, and they rapidly become slow, react slow and all.
Mono apps are a bit slower than pure Gtk apps, but Mono is getting faster all the time.
Python really does need a decent IDE, I quite agree.
Try PIDA. It’s my favorite Python IDE.
http://pida.berlios.de/
> Look at Beagle, F-Spot, Banshee, Tomboy.
My own experience:
* Beagle — pretty decent but it seems to take too much memory. I turned it off a few days after installing it.
* F-Spot — Not a bad app, but it does have one fatal shortcoming that sent me back to GQView quickly: Import seems to be the only way to get things into the system, just like Picasso. If F-Spot adds support for viewing directories or files directly or file collections specified from a text file, I might look into it again. Otherwise, it’s not worth the trouble.
* Banshee — Pretty decent, but is a bit sluggish compared to Rhythmbox and also lacks internet radio. It also seems to crash quite a bit.
* Tomboy. No opinion. I tried it and didn’t find it useful but I didn’t find sticky notes useful either so I’ll leave it to the sticky enthusiasts to figure out the differences.
* MonoDevelop — Supports only Mono apps. If you’re a Mono developer, it’s great. Otherwise, you’re out of luck, so I wouldn’t call it generally useful. My personal favourite for multi-lingual programming is Eclipse (based on Gtk+ too), although JEdit is a close second. SciTE used to be a favourite but it added a “feature” that made it unusable. Previously, if you opened a file in a directory and wanted to open another file, it stayed in the directory you opened this file. This made sense since project files tend to be in the same directory. Now, it resets to the “Documents” directory each time. Why? Documents has a short-cut, my current directory doesn’t, so I have to navagate back to my spot to open another file.
In short, Mono apps are not the best of the breed yet. From my experience, they need to work on reducing their resource usage and at the same time add features available in their C/C++ based Gtk+ counterparts or non-Gtk+ based counterparts.
* Beagle — pretty decent but it seems to take too much memory. I turned it off a few days after installing it.
Beagle has always been quite memory hungry, but it has been improving by leaps and bounds. If it’s something you’re interested in using, re-visit it every now and again. The memory usage on my Dapper laptop is considerably lower than in the Breezy era.
* F-Spot — Not a bad app, but […] Import seems to be the only way to get things into the system
This is true, however if you point Import at a top level directory, it works great. I must admit, however, if you’re not bothered about the Flikr, tagging etc integration then GQView is likely the best bet.
* Banshee — Pretty decent, but is a bit sluggish compared to Rhythmbox and also lacks internet radio.
Check it out again – the internet radio functionality has been moved out to a plugin. There’s also a lot of cool stuff going into Banshee – the latest HEAD has support for pulling music from iPods, will have an EQ. Again though, if RB suits you, and as there’s no common DB layer, you’re probably best sticking to whatever you use to avoid having to re-import and rate all your music! For more info about banshee – check out Aaron’s blog – http://abock.org/2006/07/27/more-bling-from-the-banshee-front/
People push Python but where are the showcase Gtk/Python applications? What RAD tools does Gtk/Python have?
You must be living under a rock.
http://pygtk.org/applications.html
Tomboy is superiour to sticky notes.
Tomboy takes 10mb – 26Mb RES – 16Mb SHR
Sticky notes takes 1just over 10mb – 11Mb RES – 9016 SHR
People want to do more than just what sticky notes do and it’s just old. I’m glad gnome devs have said yes to gtk#.
Actually, the base unit of the SHR column is kb… In your case, the Sticky notes applet uses about 2 Mb.
Did you made the comparison on a plain desktop, or with a few notes here and there?
Although Tomboy might not use much memory by itself, its external features might take a lot. It’s not self-contained, after all. Thus, RES should be taken in consideration.
Just a precision: SHR stands for memory that might be shared between processes.
Edited 2006-08-02 12:53
Isn’t Microsft using WinFX as a front end for Vista and XP. How does this relate to what GNOME is doing? Is GNOME going beyone what Windows is doing?
WinFX is a framework (being renamed to .NET 3.0), not a frontend.
For your other question, I don’t understand it.
WinFX is a framework (being renamed to .NET 3.0), not a frontend.
For your other question, I don’t understand it.
Ok thanks,
Mono has a large managed machine. Is it larger then say Python’s? Could Mono be cut up into smaller bites eventually? Does Java have smaller versions? I know that there is J2EE and just Java.
As in comparison to Vista or .NET3.0 you still don’t need a high end ‘locked into DX’ graphics card to run GNOME/Mono and probably not as beefy a machine but it does get rid of that lightweight appeal still I guess but maybe not. It’s just that how much larger will mono get in the future.
I dunno to me this is all so silly. When people make a program they should focus on using one language not 20.
I stick with KDE which is primarily C++ with a little Javascript they are putting in, but have liked GNOME too.
I dunno to me this is all so silly. When people make a program they should focus on using one language not 20.
The issue here is offering a top class development platform. You can have the best DE in the world, but without ISV and third party developer support, no apps = no users. I like how Gnome is designed – everything at a low level in C, bindings for those C libraries for everything from C++, to ruby, python, mono etc. This, IMO, provides that development platform that people want to code for. KDE has this in a different manner – through Qt (and various language bindings) and KParts, it can also offer a similar RAD platform as so much cool stuff is reusable.
I stick with KDE which is primarily C++ with a little Javascript they are putting in, but have liked GNOME too.
I can’t remember the application (I’m not a KDE user) but are not a couple of the “high profile” apps written with Ruby?
I can’t remember the application (I’m not a KDE user) but are not a couple of the “high profile” apps written with Ruby?
I dunno they have bindings to all the languages but only through QT not KDE, right?
http://developer.kde.org/language-bindings/
Although, I think the bigger issue is this; with the inclusion of GTK#, and there for mono; with Sun being one of the major UNIX vendors using GNOME as the foundation for their next generation desktop, are they going to embrace mono/gtk# – considering that they have a comprehensive agreement with Microsoft, covering patents and other intellectual property, they’re actually in a good position to provide the technology and at the same time assure the customer that they’ve ‘paid’ for the right to use those patented technologies – no legal worries.
The sad part, however, I’ll put money on it, Sun will rush off, and spend another several million trying to come up with java counterparts, simply to spite Mono and its supporters – don’t think thats possible, look how long it took for them to realise that the shelf life of their classic UltraSPARC is quickly coming to an end and embrace Opteron/Solaris x86.
Sometimes I think Sun needs a whole new management who are willing to be pragmatic and say, “if thats what the customer wants, then thats what we’ll provide!”
Edited 2006-08-02 10:34
The sad part, however, I’ll put money on it, Sun will rush off, and spend another several million trying to come up with java counterparts, simply to spite Mono and its supporters – don’t think thats possible, look how long it took for them to realise that the shelf life of their classic UltraSPARC is quickly coming to an end and embrace Opteron/Solaris x86.
Sometimes I think Sun needs a whole new management who are willing to be pragmatic and say, “if thats what the customer wants, then thats what we’ll provide!”
If Sun really cared about Java being a major part of the Gnome desktop, then they would have done something about it years ago. Sun seems to think that the only toolkit that anybody would/should ever be interested in is Swing. And for whatever reasons, open source desktop developers just don’t care about Java. The Java Gtk/Gnome bindings have been around for years and years and they’re just not really used.
But you make a good point about the agreements between Microsoft and Sun. Frankly, the people that start handwaving about Mono legal uncertainties just don’t want open source people using Microsoft tech and also we have some KDE fanboys that feel threatened.
If Sun really cared about Java being a major part of the Gnome desktop, then they would have done something about it years ago. Sun seems to think that the only toolkit that anybody would/should ever be interested in is Swing. And for whatever reasons, open source desktop developers just don’t care about Java. The Java Gtk/Gnome bindings have been around for years and years and they’re just not really used.
Well, there is SWT which is a wrapper/binding to gtk – if Sun, for example, invest some time, ported the whole of gtk to Cairo, Sun could then standardise on SWT/GTK for all platforms, they would get the benefits of having a cross platform toolkit, whilst at the same time, not have the massive performance and integration issues.
For the bindings, IIRC, they’re now out of date and also IIRC, they’ve been replacee with SWT/GTK+, which actually does a really nice job with integration.
But you make a good point about the agreements between Microsoft and Sun. Frankly, the people that start handwaving about Mono legal uncertainties just don’t want open source people using Microsoft tech and also we have some KDE fanboys that feel threatened.
Also, if Sun embrace Mono, start shipping with it, they’ll finally move away from the NIH syndrome; at the end of the day, if I was running Sun, I can tell you, if the customer is using a piece of Sun equipment with a copy of Solaris on it, quite frankly, what he or she runs ontop – be it Java, Mono or a something else, should be completely irrelevant.
Infact, if Sun *did* support mono, and really bought VB.NET and C# up to equal completeness as Microsofts .Net, Sun would be in a perfect position to leverage Windows developers current skill sets to expand their base of third party developers.
Imagine a customer, who has standardised on .NET and now decides that he wants to consolodate his servers on a T2000 based server, running the latest niagara server – thats a customer won if they did the above.
It isn’t new them providing Microsoft technology based solutions, they bought out Chill!soft for example, which provided ASP capabilities on UNIX.
Well, there is SWT which is a wrapper/binding to gtk – if Sun, for example, invest some time, ported the whole of gtk to Cairo, Sun could then standardise on SWT/GTK for all platforms, they would get the benefits of having a cross platform toolkit, whilst at the same time, not have the massive performance and integration issues.
SWT is problematic for right-to-left written languages (Hebrew, Arabic etc..). The BiDi interface works only on windows.
Swing in comparison supports RTL interfaces on all platforms. So does GTK+.
Well, there is SWT which is a wrapper/binding to gtk – if Sun, for example, invest some time, ported the whole of gtk to Cairo, Sun could then standardise on SWT/GTK for all platforms, they would get the benefits of having a cross platform toolkit, whilst at the same time, not have the massive performance and integration issues.
Sun has regarded the development of SWT as some kind of traitorous act by IBM (yeah…one of those Sun things once again), so you can forget about that. We can assume that Java/GTk+ hardly exists in their minds. It’s just one of those mind-boggling stances that Sun has.
Also, if Sun embrace Mono, start shipping with it, they’ll finally move away from the NIH syndrome; at the end of the day, if I was running Sun, I can tell you, if the customer is using a piece of Sun equipment with a copy of Solaris on it, quite frankly, what he or she runs ontop – be it Java, Mono or a something else, should be completely irrelevant.
Infact, if Sun *did* support mono, and really bought VB.NET and C# up to equal completeness as Microsofts .Net, Sun would be in a perfect position to leverage Windows developers current skill sets to expand their base of third party developers.
Imagine a customer, who has standardised on .NET and now decides that he wants to consolodate his servers on a T2000 based server, running the latest niagara server – thats a customer won if they did the above.
It isn’t new them providing Microsoft technology based solutions, they bought out Chill!soft for example, which provided ASP capabilities on UNIX.
Direct link for this comment
A lot of that makes sense. And since the CLR is basically a superset of the JVM, it has no problem running Java bytecode via translation. Now that Sun has decided to become a hardware and software services company it is probably wise for them to run as much as possible and support as much as possible on their hardware. Of course that reality doesn’t necessarily jibe with whatever politics goes on at Sun regarding Java.
But at the end of the day, Sun probably realizes (like most others), that there’s just no money to made on open source Unix desktops, so just doesn’t care anymore.
Sun has regarded the development of SWT as some kind of traitorous act by IBM (yeah…one of those Sun things once again), so you can forget about that. We can assume that Java/GTk+ hardly exists in their minds. It’s just one of those mind-boggling stances that Sun has.
The funniest part; they’ll opensource Solaris, but when it comes to Java, which creates NO direct form of revenue, they want to keep it closed source! forking, bullshit; considering that an implementation can’t be called Java until it has passed the certification test, the likelihood of ‘incompatible versions of java’ out there as being moot.
Imagine if they opensourced Java, we would have gotten shared JVM 4 years ago rather than the procrastination that occurs at Sun – it seems that for anything to actually get done, one basically would have to walk around with either a bloody big sword or gun, demanding that things are delivered ontime.
A lot of that makes sense. And since the CLR is basically a superset of the JVM, it has no problem running Java bytecode via translation. Now that Sun has decided to become a hardware and software services company it is probably wise for them to run as much as possible and support as much as possible on their hardware. Of course that reality doesn’t necessarily jibe with whatever politics goes on at Sun regarding Java.
But at the end of the day, Sun probably realizes (like most others), that there’s just no money to made on open source Unix desktops, so just doesn’t care anymore.
The problem with Sun, they do create UNIX desktops by virtue of their Sun Ray appliance; they do have an interest in improving it, the problem is, they would rather spend money on over priced ‘technology evangelists’ and clueless management who know sweet-f–k-all about computers, but has some how made their way to the top of the food chain.
Take this example; the New Zealand manager for Sun Microsystems doesn’t have the foggiest idea about Solaris – here is a manager, grand poobah of Sun in New Zealand, and he doesn’t have the slightest clue about the products his company is selling. Then when it comes to correspondance with said person, like Sun sales people, they seem to fall off the edge of the earth!
I’m sorry, but Sun not only needs an overhaul, but a giant kick up the ass.
The problem with Sun, they do create UNIX desktops by virtue of their Sun Ray appliance; they do have an interest in improving it, the problem is, they would rather spend money on over priced ‘technology evangelists’ and clueless management who know sweet-f–k-all about computers, but has some how made their way to the top of the food chain. [i]
It sounds like you have a gripe and a chip on your shoulder. Leaving what happens in New Zealand alone (last time I was there it just involved drinking – no sheep thanx, I’m Australian), going to the Sun Website, and looking through the exec bios’s, you would probably find there are plently of the management team which certainly do have clue.
[i]I’m sorry, but Sun not only needs an overhaul, but a giant kick up the ass
Why???
The sad part, however, I’ll put money on it, Sun will rush off, and spend another several million trying to come up with java counterparts, simply to spite Mono and its supporters – don’t think thats possible, look how long it took for them to realise that the shelf life of their classic UltraSPARC is quickly coming to an end and embrace Opteron/Solaris x86.
What is the classic UltraSPARC you talk of?? Ultra I,II? Sun certainly dont think that SPARC is coming to an end. Maybe you have not heard of the UltraIV+, or Niagra, (APL,ROCK). The SPARC development is very much alive at the moment, and is packed with plenty of preservatives.
Sometimes I think Sun needs a whole new management who are willing to be pragmatic and say, “if thats what the customer wants, then thats what we’ll provide!”
The “addition” of x86 hardware and their refocus on Solaris x86 shows that the Sun management do listen to their customers.
I’m glad that this has been decided, but people seem to forget why it is here. I seriously doubt that the gnome core will depend on Mono anytime soon with all the factions and intrest groups involved. I think we will stay C for the gnome-core for a long time to come. Likely for Topaz (gnome 3.0) as well.
The desktop application is a completely different story ofcause. Use whatever language you want. People will still have a choice to not install/remove heavy apps and replace them with their favorite light-weight tool.
People tend to forget that languages like c/c++, python and Java/C# target different purposes.
Use the right tool for the right job!
As long as Tomboy can be removed, I don’t see a problem with it.
The fancy features require some RAM. If you want to use your old Celeron with Gnome, you only use the basic apps, that’s all.
The fancy features require some RAM. If you want to use your old Celeron with Gnome, you only use the basic apps, that’s all.
I agree with many opinions reflected here that you can’t expect a modern system to run well on seven year old hardware. Of course, software should be optimized as much as possible, but that doesn’t mean that there is a need to stay in the stone age.
Yeah, (byte-)interpreted languages and modern development frameworks require more hardware resources, but they allow quicker (and arguably, more bug free) building of new GUI applications. For example, you don’t need your own hypertext renderer, one can leverage Gecko through Gecko# with just a few lines of code. And that gives a lot of room to do what most programming is about: solving the actual problem. It just doesn’t make sense if you want to write a cash register program to bother with your own implementations of hashmaps or GUI widgets, if it has been done, and done well before. I’d say power to Gtk# (and gnome-java) in GNOME.
As far as older hardware is concerned: there is no need to abandon old hardware completely. Some enterprise distributions provide support for seven years. So, you could run CentOS 2.1 (security updates until 2009), CentOS 3 (security updates until 2010) or CentOS 4 (security updates until 2012). E.g. I have a laptop with 384MB RAM that works great with CentOS 4.x, but is too slow on anything newer (like Fedora Core 5 or Ubuntu 6.06). It is not a problem, I can use CentOS 4.x on the machine securely until 2012. At that time the laptop is probably dead or obsolete
.
Edited 2006-08-02 13:01
GTK# will send GNOME to an early grave.
with any luck it’ll be the week after e17 is finished.
This could only mean one thing:
Mono optimization.
“People push Python but where are the showcase Gtk/Python applications? What RAD tools does Gtk/Python have?”
Showcase? There are a lot of python apps working fine out there. They don’t need to be showcased. What poor framework needs to be showcased…
“Mono is based on ECMA standards”
Wrong. C# is an ECMA standard.
“There is nothing Microsoft can do to pull Mono down in a court of law”
After a lot of effort and years are put on mono, let’s see if Microsoft stays quiet or not.
“So not only is Mono legally sound, it is also capable of defending itself.”
Oh, yeah, they put a retrovirus in the code.
>”Mono is based on ECMA standards”
>
>Wrong. C# is an ECMA standard.
Mono includes implementations of things that are NOT standardised, sure – so does gcc.
The CLI is standardised.
The standardised bits are listed here:
http://msdn.microsoft.com/netframework/ecma/
Which of the alternatives to C#/CLI have de jure standards?
I seem to remember there was a time when pro-POSIX lobbyist (read anti-MS brigade) made a big deal about the benefit of de jure standards over de facto ones. Are we saying now that de facto wins?
Microsoft have at least made some effort to play fair with C# and CLI, even if their motivation is primarily to annoy Sun.
I believe that if you look at the mono build profiles, you can explicitly choose to build an ECMA system. What more do they have to do to be acceptable?
“Hmmm… i sort of understand, but what is different between .exe and an executable .sh or .py for that matter … nothing really, apart from the ending.”
Well, there’s no MZ in my .sh headers
“Why? It’s little more than a different file extension and file format. You could name all your Linux programs with .exe and they will still work just fine
”
They won’t work collectively.
Please read this: http://www.gnome.org/~seth/blog/mono
Kick off Novell and/or Gtk# or fork Gnome to stay FOSS. That’s all.
Seth wrote that blog post over two years ago, and a lot has happened since then. Most importantly, the Open Invention Network:
http://en.wikipedia.org/wiki/Open_Invention_Network
OIN makes Mono (and many other Free software projects) untouchable by Microsoft.
The OIN is also what finally caused the Fedora Project to include Mono.
Edit: I don’t speak for Seth of course. I don’t know Seth, and I have no idea what his thoughts on Mono are nowadays.
Edited 2006-08-02 15:23
OIN makes Mono (and many other Free software projects) untouchable by Microsoft.
It does no such thing. It’s simply a deterrent to Microsoft by saying you sue us, we sue you for something completely unrelated.
Never underestimate a threatened Microsoft. Having said that, I doubt they would sue unless they had no other option.
But people miss the point that Microsoft doesn’t have to sue. The mere threat that they can, the mere implication that there are patent issues, taints the project.
There are very serious implications for commercial and institutional customers with regards to IP. As someone who has worked on procurement contracts in the past for government and enterprise organizations, I know that IP indemnification is almost always a requirement.
Novell offers indemnification, although they’re not clear on whether that extends to mono. Will IBM indemnify mono? Will Red Hat? Will HP? Will Sun? Are customers expected to use it at their own risk? Don’t underestimate the convservative nature of business, we can scoff at the SCO lawsuit but it raised some very valid concerns that will not go away.
Or is mono really just a pseudo-community project that is owned and operated by Novell? How much support will other distributors really put into it? One of the biggest challenges and most frustrating obstacles to wider spread linux adoption seems to be the community’s frequent obliviousness to the real world requirements of users. (And in fairness, I’m not singling out any particular group or project on that point, it’s fairly widespread).
OIN doesn’t protect mono from patent infringement. It’s a deterrent. An effective one, but not an absolute one. That’s the point people seem to overlook, but responsible organizations cannot.
In the end, I don’t really care, I don’t need mono right now so I’m mostly watching from the sidelines. But I guess what really gets my goat is the hypocrisy from many in the Gnome community, particularly many of those backing mono, that slag Qt’s dual-licensing because of it’s clear corporate ownership, and embrace mono despite it’s questionable licensing issues and it’s clear corporate ownership. Seems to me like it’s really more of a pissing contest after all, rather than what’s actually good for the Gnome or broader communities.
Bah.
Kick off Novell
I’m sure your personal crusade to “kick off Novell” should be interesting.
“I can’t remember the application (I’m not a KDE user) but are not a couple of the “high profile” apps written with Ruby?”
Nop, C++ and perhaps a couple of Ruby/Python plugins.
I dunno to me this is all so silly. When people make a program they should focus on using one language not 20.
I have to respectfully disagree. In almost every case, it is better to write every part of your program in the most restrictive and/or highest-level language that you can. In fact, if part of your program can be written in a language that isn’t Turing-complete, it should be.
You laugh, but have you used SQL? How about regular expressions? These are specialized languages which are certainly not Turing-complete, but which specify actions on their domain in a much simpler and more straightforward way than if a general-purpose language were used instead.
People use regular expressions and SQL, despite the fact that the two languages are significantly less powerful than using a general-purpose language, for two related reasons: the domain languages are /so/ much simpler, and as a result, you’re significantly less likely to make a mistake. Imagine if you wanted to search for all occurrences of the regexp ‘h[i|ello] there’. You’d have to search the string for an ‘h’, then check if the next character is an ‘i’ or an ‘e’, then if it’s an ‘e’ check if the next three characters are ‘llo’, then look for ‘ there’. Significantly more work and a whole stable of procedures, and this is for a trivial example.
Here’s another example. If you’re writing a GUI in Qt, for example, you’d be a fool not to use Designer. Designer saves its output in certainly-not-Turing-complete .ui XML files, which are processed by the uic tool. The uic program translates .ui files into clean C++ code, which is then referenced by (but not included in) your code. By using uic instead of writing the code by hand, you guarantee that your UI will not crash or corrupt your system, which is more than you can say if you wrote the code by hand.
While the argument is less clear when you’re comparing general-purpose languages, it’s still just as valid. If I can replace a 100-line C function with a 1-line Python library call, then I should, unless the Python version is unreasonably slow. The Python developers are much more likely to have gotten the code right than I am. Since I’m not the only one who uses Python, if there were bugs they’d probably have been discovered already. And if something is discovered later, it’s much simpler to fix the language than every program that decided to roll its own version of the function.
A major reason why KDE is primarily C++ is that C++, in combination with Qt, feels very much like a high-level language. C++/Qt code would certainly be shorter and easier to understand than the equivalent Java code. The benefits from writing code in PyQt or QtRuby are balanced by the fact that the bindings are far from complete or well-documented, and by the fact that the bindings generally provide a very similar API to Qt/C++ — meaning that there are no opportunities to replace 100 lines of code with 1. The few pieces of the application logic which don’t depend on the Qt API are likely to be the pieces that you would rewrite in a faster language anyway.
On the other hand, computers are getting fast enough that, for many programs, even that non-GUI logic can be written in Python or Ruby without a significant speed decrease. And the bindings are getting better. (Trolltech might even release one of their own; the FAQ page for Qt Jambi said that they would consider bindings for other languages if Jambi was popular.) So we will probably see more KDE apps written in Python or Ruby in the future, with significantly less uproar from the community.
As someone who uses Sticky Notes nearly every day and actively dislikes Tomboy, this is not very good news. Perhaps the days of simple tools that do simple jobs are past us. If I want a text editor with a big toolbar to write notes with, I’ll load up gvim. Sometimes I just want a small yellow block on my screen with a note. sigh
It’s a real shame that Novell seems to have such leverage on the gnome community.
“It’s a real shame that Novell seems to have such leverage on the gnome community.”
Alex Graveley works at WMware. You’re not payed one Euro for each comment you submit, at least try to get the facts right.
Edited 2006-08-02 17:09
The Novell comment was a side thought about the overall expansion of Mono influence on gnome…not about Tomboy or Alex Graveley. Thanks.
“The Novell comment was a side thought about the overall expansion of Mono influence on gnome…not about Tomboy or Alex Graveley. Thanks.”
The whole Mono influence on Gnome is a proposal to include Tomboy. Thanks.
“The whole Mono influence on Gnome is a proposal to include Tomboy.”
Well, that’s how it begins. I use f-spot and, occasionally, banshee, and am not anti-Mono by any means. As with many others, it would seem, I just do not feel that the Mono runtime has a place in the default gnome desktop. I also work with a number of Solaris systems and hope this does not have a negative effect on Sun’s use of gnome as a desktop. If there was a more compelling application or reason I might have a change of mind. But including an entire runtime in order to support a little note taking app seems a tad excessive. shrug
More skilled writers with more insight into Gnome than I have better elaborated the problems so it’s pointless for me to rehash them. In addition, your tone makes it clear that you’ve already made up your mind on the matter and are not open to other ideas.
” believe that if you look at the mono build profiles, you can explicitly choose to build an ECMA system. What more do they have to do to be acceptable?”
Give up on patents?
“I run 64bit linux and with mono apps I don’t have to have compat 32bit libraries”
My Linux is 64 bits as my KDE packages. Most applications are compiled for 64 bits already. I don’t understand how mono applications are supposed to get advantage of AMD64, with more registers and new opcodes. Only compiled for AMD64 applications get this advantage, thus C/C++ applications.
I don’t understand how mono applications are supposed to get advantage of AMD64, with more registers and new opcodes.
Mono applications can take advantage of AMD64 by running under a JIT which makes use of AMD64 registers & opcodes.
In short, upgrade the JIT (the mono program and libmono.so) so that it targets AMD64 instead of x86.
As this has already been done, all Mono applications can already take advantage of AMD64 registers & opcodes…
…With one exception: dependencies. Any non-trivial C# application will eventually rely on [DllImport] statements which invoke native libraries. (For example, Gtk# is basically a bunch of [DllImport]’s for the GTK+ libraries.) In order for a AMD64 mono to work, all of the dependencies your application uses must also be compiled for AMD64.
Since that has already been (largely) done, it should be possible to make full use of your AMD64 processor with mono now.
“Seems to me like it’s really more of a pissing contest after all, rather than what’s actually good for the Gnome or broader communities.”
That’s what I don’t like about GNOME. There’s too much companies around taking decissions. On one hand it’s convenient, for companies. On the other hand, the community process may get hurt by this.
“no, we are not going to hold up progress for people driving model Ts. go download fluxbox and stop insisting the world move back to the 90s.”
Well, that’s totally subjective, calling the mono inclusion in GNOME a progress. I think it’s going to be a major blow for GNOMErs outside the Novell umbrella. Users don’t give a shit about that, but developers… you know, the guys that make GNOME…
It’s not probable/desirable a GNOME fork. If things get nasty then they will get rid of the crap mono is. Who needs it, anyway? You can do the same with Python/Ruby/Perl. So better improve their interpreters, finish parrot and don’t code those things that are mostly fit for C/C++ in a slower and resource hungry framework. Lazyness is not an excuse. it may be MS excuse.
“You’re not payed one Euro for each comment you submit, at least try to get the facts right. ”
And you are not payed with gold to be an asshole. His opinion counts as much as yours.
“Frankly, the people that start handwaving about Mono legal uncertainties just don’t want open source people using Microsoft tech and also we have some KDE fanboys that feel threatened.”
Well, my opinion: KDE has nothing to feel threatened for. It’s a community project, not a company project. If people or companies use KDE or not, that depends on them. As long as this shit about mono doesn’t touch us…
GNOME should feel threatened. The project may end loosing some of their developers.
As long as this shit about mono doesn’t touch us…
You have no say in what others use.
GNOME should feel threatened. The project may end loosing some of their developers.
Actually, Gnome will gain many more potential .NET developers. Good ridance to those that leave.
sbenitezb, and since you run KDE and have been furiously denouncing Mono we know that you do feel threatened.
“sbenitezb, and since you run KDE and have been furiously denouncing Mono we know that you do feel threatened.”
No, I don’t. Why should I, if I use KDE? But a lot of GNOME users/developers will.
No, I don’t. Why should I, if I use KDE? But a lot of GNOME users/developers will.
Nope, you don’t speak for Gnome developers or users. So why are you threatened by software that other people use?
“I’m sure your personal crusade to “kick off Novell” should be interesting.”
GNOME doesn’t need Novell. Novell needs GNOME.
GNOME doesn’t need Novell. Novell needs GNOME.
Novell employees Gnome developers. Gnome is developers, not some person.
“Novell employees Gnome developers. Gnome is developers, not some person.”
And what makes you think that Novell employs all GNOME developers?
“Novell employees Gnome developers. Gnome is developers, not some person.”
And what makes you think that Novell employs all GNOME developers?
Try reading what has been written next time.
“Since that has already been (largely) done, it should be possible to make full use of your AMD64 processor with mono now.”
Well, for sure I make full use of my AMD64 processor now with compiled applications (I’ve done an objdump -d to check this is true). Perhaps I’m a bit too reluctant to agree with you on mono working exactly the same. If I objdump -d a mono application will I see function parameters passed in registers?
I welcome gtk#/mono as part of gnome as a good thing. IMO it means potentially more applications for Gnome, which benefits end users (who for the most part don’t even know what the GPL is much less the legal intricacies of patent law covering .Net implementations). Not because gtk#/mono apps are better than those written in C++/python/ruby/smalltalk/etc, but because those who do code in .Net will be more likely to release versions of their apps that run on Linux. Of course they can do that already, but this makes it more likely that it will happen.
True Tomboy is slower than StickyNotes and uses more memory, but both have their place. I use both daily in my work, for completely different purposes. But StickyNotes will still be there for those who want it as an optional install (like Tomboy is today). It would be nice if Tomboy could be less sluggish (I don’t know if it’s a mono problem or a Tomboy problem), but it’s an excellent program and a good addition to Gnome, IMO.
I’ve also been very pleased with the mono apps I’ve used so far in Dapper, such as f-spot and banshee. If gtk#/mono in Gnome means possibly getting more apps like those (and continued improvement of those, which are still beta), I say that’s a great thing.
[quote] Novell employees Gnome developers. Gnome is developers, not some person. [/quote]
actually , gnome started and grew without novell .. so gnome doesnt need novell.
that “gnome is developers” …. reminds me of ballmer ( is it good ?i dunno , sudently , MS , NET , ASP are all the good techlonogies )
actually , gnome started and grew without novell ..
Actually, the guys that created GNOME are now working at Novell.
Actually, the guys that created GNOME are now working at Novell.
Yes and this way they have a lot of influence. They want Mono, so they sponsor it. But not for free: they are a company, so they have to sell things. As long as it pays they will go on. If it does not, they will be out of this business. If Microsoft sues them, they will be out of this business too.
You know what I am saying: They care for their profits, nothing more. They don’t care about FOSS or any ideals behind that.
Actually, the guys that created GNOME are now working at Novell.
So that’s where they went, as to the complaint Thom had.
Also .NET is the main API in Vista, although it is backed by C lightly, it’s still the main API so to me the success it has with Vista should mirror the success it has with GNOME as letting Mono in GNOME will only make it the main part of GNOME eventually. Why let in a massive framework and not make it the main API. Sneaky. Come on, I know whet the Mono people are up to. 🙂
Extra thought:
I don’t agree with MS’ new assertion that the Internet is the prime thing in technology. It’s the computer and the storage device. This makes me think MS is moving toward more dynamic languages and becoming just an Internet company. NOTE: Google is not just an Internet company,
Also coders should have a slight respect for C or C++. Both or just one, or they are only webmaster people dealing with virtual languages that are usually backed by C anyway. Webmaster people are awesome though, Iv’e done webwork, but I notice sometimes they loose track of native languages. I am afraid of the Internet taking over too much with Web 2.0 as people might have a harder time privately holding on to data with a home storage device.
You know what I am saying: They care for their profits, nothing more. They don’t care about FOSS or any ideals behind that.
They do still care about FOSS, otherwise they wouldn’t spend time on participating in online-activities or developer conferences.
They might do less hacking than they used to but any contributor can change their area of contribution and still be a valuable member of the project
I dunno they have bindings to all the languages but only through QT not KDE, right?
The bindings listed at the URL you provided are KDE bindings, meaning they bind to the APIs provided by the KDE libs.
They usually include bindings to Qt unless the respective Qt bindings are maintained by a different project
OK, how would this compare to what GNOME is doing with Mono. Is KDE doing this with C#?
KDE uses bindings to C# they dont put the entire Mono compiler iin there.
Well, I think gtk# and gnome# are the best things that can happen to gnome.