Tomboy, Gnote, and the limits of forks
So what are the problems with Tomboy? For your editor, at least, the biggest issue is the simple sluggishness of the tool. It is a large program which takes quite some time to start up. If one tries to bring up a note on a system which has been used for other things, there can be a lengthy delay before the menu from the taskbar icon appears. Rightly or wrongly, users blame this fundamental slowness on Tomboy's use of the Mono platform. Now, of course, use of Mono brings in a whole host of other complaints, but we need not consider those here. The simple fact is that Mono adds a great deal of baggage to what should be a small and simple application. A basic note-taking tool should not be a heavyweight program.
Gnote is a reimplementation of Tomboy's functionality using C++ and GTK+. In a sense, though, it is not an independently-developed application. Instead, Gnote is a straightforward port of the original C# code to C++. So it's not just a Tomboy work-alike; it's a true clone. There are advantages to this approach; it makes use of the experience which has gone into Tomboy development, and compatibility with the Tomboy file format is not a problem. This approach enabled Hubert to put together a working application in a relatively short time.
Some distributors (Fedora, at least) have made Gnote packages available. Your editor played with the Rawhide version of Gnote for a bit; it is, in general, indistinguishable from Tomboy. It does seem more responsive, especially when the system is under some memory pressure. Annoyingly, it does not (unlike Tomboy) dismiss notes when the escape key is hit. Beyond that, though, Tomboy users (at least those who do not use plugins) will be hard-put to tell the difference between the two.
It is said that imitation is the sincerest form of flattery; if that is true, one would expect the Tomboy developers to be flattered indeed. But a web log entry about the Tomboy 0.14.1 release made it clear that "flattered" may not be the operative word in the Tomboy camp:
Tomboy is not going away, and it will continue to be developed on the extremely productive Mono/GTK# language platform. Anyone thinking about distributing Gnote should consider the impact on users and their data. When we develop, we should always be asking ourselves, "is this adding value for our users?"
It should not come as a surprise that this language inspired a lot of responses, on the original site and elsewhere. Reading through the discussions, your editor has come to a couple of conclusions:
- The Tomboy development community obviously sees Gnote as a threat. It's
not entirely clear why that should be. If these developers are paying
attention to what they are doing, and if the Mono platform is as
"extremely productive" as they say, they should have no trouble
staying ahead of Gnote. Beyond that, the existence of other, interoperable
applications should serve to grow the community as a whole.
- Gnote clearly has added value for some users. There is a significant community out there which does not want to have Mono on its systems. One may or may not agree with their reasoning, but one cannot argue with the fact that these users exist; simply dismissing their concerns is unlikely to change their minds. Mono-free, Tomboy-like functionality adds value for those users.
It is evident that some developers and users in the Tomboy camp think that the creation of Gnote is an improper thing to do. The creation of a new application by translating code into another language seems unoriginal at best, and a misappropriation of the code at worst. The fact that the code has been relicensed (from LGPL 2+ to GPLv3) in the translation process has not helped. But it should be remembered that both the translation and the relicensing are acts which are allowed by the license chosen by the Tomboy developers. The LGPL license text packaged with the Tomboy code reads:
Other parts of Tomboy carry GPLv2+ or BSD licenses; it's actually quite a mixture, but they all allow conversion to GPLv3. So Hubert has only done what the original developers explicitly allowed him to do; about the only complaint one might make is that he appears to not have carried the copyright attributions over into his translated code. That, probably, is an omission which needs to be fixed; it would be hard to argue that Gnote is not derived from Tomboy.
Beyond that, there are concerns that Gnote will take developer attention away from Tomboy. That could be true, but chances are that any developers working on Gnote (and it's not clear that there are any, beyond Hubert) are unlikely to have been working on Tomboy previously. There is also concern about what happens if and when Tomboy and Gnote diverge from each other. That could well happen; Hubert does not appear to have promised to mirror Tomboy forever. Should things go that way, Gnote really just becomes another fork; it will live or die on its own merits.
It will take time to know whether hacking on Gnote is a wise use of Hubert's time.
But it is a clear example of what is good about free software: a developer
with a specific itch was able to scratch it (for himself and for others)
without having to start from the beginning. Criticisms of Gnote
would seem to be misplaced, and attempts to suppress it (and telling
distributors that distributing Gnote is a threat to their users' data can
only be seen as such an attempt) even more so. Free software means letting
others take your code in directions you may not always approve of.
Posted May 1, 2009 20:32 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (6 responses)
For example, if Android becomes a popular netbook OS, the constraints of the development environment make it that much more likely that you see application level functionality that currently exists in python and mono languages rewritten for Android's java platform to fill up the Android online apps store.
-jef
Posted May 1, 2009 20:40 UTC (Fri)
by corbet (editor, #1)
[Link] (5 responses)
You mean...something like Tomdroid...? I meant to mention that in the article, but it slipped my mind. I forgot to put it on that little Tomboy note...
Posted May 1, 2009 21:03 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (4 responses)
Having 17 different coding languages to choose from is nice and all. But I think we've gotten very accustomed to "fat" environments in our little niche of the linux enthusiast world that we live in. Its an all you can eat buffet of development tools and interpreters and libraries and what not.
And I say that without trying to single out any particular language or framework. Mono for all I know might actually be the best thing since sliced bread. But the marginal technical superiority of any one language or framework is immaterial to the issue at hand.
The real "fun" in product design is understanding what to throw out and what to leave in to build a maintainable framework to build on top in a coherent way. These are the sort of decisions that actually let you define an SDK for others to target. I'm sure python and mono developers around the world curse Android's constrained approach to providing a platform. But its that constrained approach which might very well make Android rise above as a platform for the phone and netbook market.
In contrast to Android, GNOME has traditionally avoided choosing a defacto programming language framework as part of the project. This is both a blessing and a curse for GNOME as a project. Because GNOME isn't product focused they can be a breeding ground for more ideas by making room for different developer communities which have self-organized around different languages. But at the same time, it makes GNOME harder to position as a coherent framework "product" for devices.
I'd love to see Novell come out of the gates with a mono based framework to build a coherent interface around similar to Android's java based framework just to complicate the discussion even further so we can see java apps ported to mono..for symmetry.
-jef
Posted May 1, 2009 21:55 UTC (Fri)
by smoogen (subscriber, #97)
[Link] (1 responses)
Posted May 1, 2009 22:17 UTC (Fri)
by halla (subscriber, #14185)
[Link]
Posted May 2, 2009 6:29 UTC (Sat)
by dkite (guest, #4577)
[Link] (1 responses)
You say that like its a bad thing.
That being said, someone has to support all the various bindings over
And yes there is code in kdebindings for ruby, but they are periodically
So, if there are too many, the inexorable thrust in this racket to a
Derek
Posted May 2, 2009 17:48 UTC (Sat)
by jspaleta (subscriber, #50639)
[Link]
What I am saying is they aren't the easiest sort of dining experience to package up and ship in a box to be sold on retail shelves virtual or otherwise.
I'm not saying that the inclusive development environment mentality is 'bad' I'm saying it has advantages and disadvantages. The disipline of a constrained development environment has its own advantages and disadvantages. We'll continue to see useful functionality created in the "fat" environment repeatedly cloned into each of several constrained environments if and when the functionality is useful. The fact that Gnote and tomdroid exists says far more about the usefulness of the tomboy functionality than it does about mono itself.
I can't wait for Novell to poop out an OS platform to compete with Android that has a constrained development environment based on mono instead of java.
-jef
Posted May 1, 2009 21:04 UTC (Fri)
by dw (subscriber, #12017)
[Link] (8 responses)
Posted May 1, 2009 21:56 UTC (Fri)
by smoogen (subscriber, #97)
[Link] (7 responses)
Posted May 1, 2009 22:48 UTC (Fri)
by corbet (editor, #1)
[Link] (3 responses)
Posted May 1, 2009 22:54 UTC (Fri)
by smoogen (subscriber, #97)
[Link] (1 responses)
its the kettle calling the pot burnt...
Posted May 6, 2009 20:39 UTC (Wed)
by ikm (guest, #493)
[Link]
Posted May 9, 2009 1:42 UTC (Sat)
by roelofs (guest, #2599)
[Link]
Indeed. Almost half of his hairs are still that orangish color!
:-)
Posted May 2, 2009 23:14 UTC (Sat)
by man_ls (guest, #15091)
[Link] (2 responses)
And speaking of old: it would be good to compare with some oldies goldies. The old Mac OS note-taking application (not to confuse with the infamous Lotus Notes) was quite useful, the only disadvantage was its irregular tendency to drop notes, at least on System 7. Does this new breed of note-taking applications bring anything new to the table, or is it just a rehashing?
Posted May 5, 2009 19:40 UTC (Tue)
by salimma (subscriber, #34460)
[Link] (1 responses)
Posted May 14, 2009 11:46 UTC (Thu)
by ketilmalde (guest, #18719)
[Link]
I'm not sure which application is referred to, but I distinctly remember a Mac applications called 'hypercard'. Back in, I guess, 1963 or thereabouts.
-k
Posted May 1, 2009 21:19 UTC (Fri)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Posted May 3, 2009 3:31 UTC (Sun)
by sitaram (guest, #5959)
[Link]
So that's 3 implementations for one application (which in this case happens to be a language spec). The tomboys might argue the same thing: duplication of bugs, developer time diluted, etc etc. I have not been lurking much in the perl 6 community lately but what little I have lurked, there don't seem to be any such "ZOMG forks!" fears there.
Perhaps the tomboys should become tommen?
Posted May 1, 2009 21:21 UTC (Fri)
by sbergman27 (guest, #10767)
[Link] (72 responses)
There's a lot not to like about Mono *long* before one even gets to the political stuff.
Posted May 1, 2009 21:56 UTC (Fri)
by ncm (guest, #165)
[Link] (7 responses)
Posted May 1, 2009 23:31 UTC (Fri)
by paravoid (subscriber, #32869)
[Link] (6 responses)
Posted May 2, 2009 0:18 UTC (Sat)
by ncm (guest, #165)
[Link] (5 responses)
Posted May 2, 2009 1:18 UTC (Sat)
by dmarti (subscriber, #11625)
[Link] (4 responses)
sudo apt-get install cdbs intltool libatk1.0-0 libboost-dev libboost-filesystem1.34.1 libboost-filesystem-dev libboost-regex1.34.1 libboost-regex-dev libboost-test-dev libc6 libcairo2 libcairomm-1.0-1 libfontconfig1 libfreetype6 libgcc1 libgconf2-4 libgconf2-dev libglib2.0-0 libglibmm-2.4-1c2a libglibmm-2.4-dev libgtk2.0-0 libgtkmm-2.4-1c2a libgtkmm-2.4-dev libpango1.0-0 libpangomm-1.4-1 libpng12-0 libsigc++-2.0-0c2a libstdc++6 libuuid1 libx11-6 libxml2 libxml++2.6-2 libxml++2.6-dev libxrender1 uuid-dev zlib1g
./autogen.sh
make
make install.
works for me but If I knew the compile would take that long I would have put my wet socks by the exhaust fan. The new notes do pop up quickly though. Esc doesn't make a note go away but ctrl-w does.
Posted May 2, 2009 4:32 UTC (Sat)
by ncm (guest, #165)
[Link]
Posted May 3, 2009 4:04 UTC (Sun)
by yvesjmt (guest, #38201)
[Link] (2 responses)
http://bugzilla.gnome.org/show_bug.cgi?id=581151
Posted May 14, 2009 11:52 UTC (Thu)
by ketilmalde (guest, #18719)
[Link] (1 responses)
I realize that various applications want me to use Shift-Ctl-W, ESC, or Alt-F4 - it never occured to me that anybody thought this was a good thing.
Posted May 15, 2009 2:47 UTC (Fri)
by zenaan (guest, #3778)
[Link]
Perhaps there's a bit of a slippery slope for what is a "standard windowing system" keybinding vs what is "application specific" keybinding?
For example with some applications, zoom in and out is CTRL-+ and CTRL--, like with Firefox. But with GIMP, it's just + and -. Yet for the "graphics/ web developer" + and - would probably be the more "standard". Should "zoom" be a window manager standard 'event'.
I vote +1 for window manager/ desktop-environment 'zoom' event.
I guess someone ought to raise the matter with freedesktop.org to discuss such things.
Many UI gripes (inconsistencies) can be levelled at the libre desktops these days, but it's getting better each year (eg OpenOffice writer, at least the version I've got installed which may have been native download, therefore not a 'packaged for my distro' version, does not honour my system/ gnome setting for external application 'Browser' - instead, oowriter always opens up firefox when I click a link. And I couldn't google any way to change this behaviour, so I currently guess it is compiled in).
Posted May 2, 2009 1:07 UTC (Sat)
by drag (guest, #31333)
[Link] (13 responses)
But Tomboy is fast enough.
---------------------
As far as Beagle vs Tracker... Tracker is faster, but it doesn't index or pull metadata as nearly as well, or support as many formats as Beagle does. Nor does it descend into compressed files (at least it didn't last time I used it) and a dozen or so other features that Beagle has had for a long time now.
If your comparing Tracker vs Beagle you might as well do in slocate vs Beagle for all the relevence of it. It's a Apples to Oranges comparison.
Tracker may reach the same level of sophistication that Beagle has offered for a long long time now, but it's not going to happen any time soon and it's probably going to end up relying on many other projects to do it's job.. which is fine. Either way it's going to require Tracker to bloat up quite a bit.
Posted May 2, 2009 2:22 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (12 responses)
You are going to need to support that claim with evidence. It was probably true in 2006. But over the last year or two?
"""
That was not even true in 2006, and I'm skeptical that you could be so poorly informed as to actually believe what you are saying.
Beagle was on course to be the standard indexing utility for Gnome. But Tracker has *long* replaced it in Ubuntu and Fedora, which together probably represent a majority of desktops, and likely in other distros, as well, with the notable exception of Suse/OpenSuse for obvious political reasons.
Ubuntu and Fedora both include Mono, so there is no extraneous political pressure for them to choose Tracker over Beagle. So far as I can see, the decisions were based upon relative *technical* merit.
This post from Rahul, dated 1.75 years ago, sheds a lot of light on the truth:
http://osdir.com/ml/linux.redhat.fedora.desktop/2007-08/m...
And yes, it *is* annoying the way Beagle silently goes into infinite loop la-la land, requiring a restart once you notice that its not indexing anymore, but sucking up 100% processor doing nothing, instead.
One last note. The Beagle guys kyped the core of their project from Apache by porting Apache Lucene from Java to C#! And even with that tremendous head start, both temporally and with regards to having Lucene handed them on a silver platter, and in addition to using such a "powerful" and "productive" platform as Mono, they *still* have been shown up by a few guys, with no corporate sponsor, who are good with C.
Posted May 2, 2009 3:37 UTC (Sat)
by drag (guest, #31333)
[Link] (11 responses)
It probably has more to do with the fact that tracker is less invasive and uses less resources, and was adopted by Gnome, then any sort of feature parity.
> You are going to need to support that claim with evidence. It was probably true in 2006. But over the last year or two?
Well then they probably need to update their webpage then.
Lets see... How is Trackers Gzip file support? Can it recursively descend into archives yet? Or how is that Kmail support comming along? I am sure that Tracker does a good job keeping track of your IRC logs. I like Tracker (and prefer it to Beagle), but that it doesn't have the same level of file support that Beagle does.
> they *still* have been shown up by a few guys, with no corporate sponsor, who are good with C.
You keep saying stuff like that. But I don't think that it was the Beagle project that had to spend pretty much the entire last year refactoring their code instead of improving support or getting releases out the door.
Oh, and getting paid to make _Free_ software kicks serious ass, so kudos to Novell for sponsoring projects and putting money into the Linux desktop.
> And yes, it *is* annoying the way Beagle silently goes into infinite loop la-la land, requiring a restart once you notice that its not indexing anymore, but sucking up 100% processor doing nothing, instead.
Last time I checked Tracker has bugs, too. In fact I am very familar with having to hide large files (say bigger then 500MB or so), bittorrent activity, and fuse-mounted file systems away from Tracker because it would choke and cause excessive drive activity and cpu usage.
And like I said comparing Tracker and Beagle is Apples to Oranges. They do 'search' and they are for 'the desktop', but they are taking different approaches.
Posted May 2, 2009 5:05 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (9 responses)
...
I like Tracker (and prefer it to Beagle), but...
Whatever feature differences there might be, they don't seem to be features that many (people, distros, DEs, you) care enough about enough to use Beagle instead of Tracker, and pay the penalty in resources that Beagle incurs. (Some would unkindly call that bloat.) Kmail indexing might be a good point. But don't most of those folks use Strigi, anyway?
Based upon usage, it appears that on the balance Tracker does, indeed, have the better product when the costs and benefits are all taken into account. Which is what really counts at the end of the day, no matter how well Beagle might make coffee. Especially if the coffee is $5 a cup.
Posted May 2, 2009 7:24 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (7 responses)
While Tracker and Beagle are both available in the repository and Beagle was installed by default several releases back, neither of them are the default at the moment in Fedora. Beagle was having a number of hard to debug memory leaks and Tracker was not mature enough yet. Tracker can still be proposed by default however and has a good chance of making it in now.
Fedora has removed Mono and Mono dependent apps like Tomboy and F-Spot from the Live CD due to lack of space so apps not using Mono just has a higher chance of being made defaults just considering the space constraints and without going into other Mono criticisms. The technical merits alone would be enough to decide one way or the other.
Drag - you are wrong about GNOME adopting Tracker. Neither Tracker nor Beagle is part of GNOME officially.
Posted May 2, 2009 16:37 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (5 responses)
So the app written in the managed environment was having tough to crack memory leak problems which were serious enough to cause its removal from default status, whereas the C++ app did not? That's certainly a little gem.
I stand corrected on the "Tracker is default in Fedora" issue. I had thought that it was installed by default in my last Fedora install, but that was well over a year ago and I could easily be remembering incorrectly. Tracker is, however, most definitely the default for Ubuntu.
Posted May 2, 2009 17:32 UTC (Sat)
by james_w (guest, #51167)
[Link] (2 responses)
Afraid not. Tracker is no longer present on new Ubuntu installations by
Posted May 2, 2009 18:10 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (1 responses)
Posted May 2, 2009 20:50 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 2, 2009 21:07 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted May 6, 2009 1:45 UTC (Wed)
by shmget (guest, #58347)
[Link]
Yet they are widely claimed as such...
----
Posted May 2, 2009 19:58 UTC (Sat)
by drag (guest, #31333)
[Link]
Oh. I thought that I read that they did. But I guess they'll have to pick something for Gnome 3.0-land. I am hoping that after the refactoring that they'd be able to get some impressive results...
Posted May 3, 2009 10:01 UTC (Sun)
by oever (guest, #987)
[Link]
Posted May 15, 2009 13:21 UTC (Fri)
by hozelda (guest, #19341)
[Link]
Don't pretend Csharp is magical and obviates the need for its users to refactor. As soon as you talk about a design decision above the language differences or existing api differences level, refactoring cannot be factored out.
In addition, C offers opportunities to cut fat out by refactoring in ways you might not be able to if you are limited to a high level API or should you use a language without enough resolution.
Posted May 2, 2009 9:46 UTC (Sat)
by jamesh (guest, #1159)
[Link] (31 responses)
The actual work of designing and implementing GNote was mostly done by the Tomboy developers in C#. The GNote translation doesn't give much indication either way about how productive a developer would be developing an application from scratch in C++ with gtkmm.
Posted May 2, 2009 19:33 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (30 responses)
However, Hubert doesn't seem to have had much difficulty. Basically just a lot of typing and grunt-work:
http://www.figuiere.net/hub/blog/?2009/04/01/656-porting-...
(Considering the concrete results now available, I think we can disregard the unfortunate April 1 date on the linked blog entry.)
BTW, just an unrelated note of explanation here. I haven't commented on the topic of this story, about forking, porting others' code to another language, and converting between GPL versions, because I absolutely don't
Posted May 2, 2009 20:12 UTC (Sat)
by drag (guest, #31333)
[Link] (28 responses)
Well 'productivity advantages' means 'reduce amount of time that it takes to get stuff done'.
The supposed advantage to higher-level languages is that they provide language features that are commonly used or desired by programmers. So that way they are not forced to rewrite the same bits of code over and over again... the language provides generic methods to do common tasks. It's not so much that C# has the ability to do things that C++ or C can't.. It's just that it takes care of things that programmers frequently will have to do anyways.
So since Mono was written in C (or C++, I don't know the details) then the fact that somebody is able to take a C# program and rewrite it in C++ is of zero surprise.
---------------------
In fact it's a potentially productive way to write application is to write something in a high level language, like python, until you get the design of the program done. Then you do profiling and try to get the program as fast as you can by choosing better algorithms.. then eventually taking those optimized algorithms and seperating them off into C-writen modules.
The trick is that unless you have the program already written it's going to be exceedingly difficult to know the design of the program. So this optimizes the time of programmer's to crank out design as fast as they can and then when that is finalized then they can concentrate on optimizations were they really count.
That is the theory anyways.
A recent success story of this sort of approach would be Git. That is that it was written using a combination of C, Perl, and Shell and as the program matures the perl and shell portions are gradually getting replaced. Even though git was originally written in high level languages it was able to easily out perform other contemporary version control systems that were mature and written in pure C or pure C++. Of course better design and Linus had a lot to do with it, but it's still a interesting case study.
---------
That is the sort of thing I am a big fan off.. combination of C and high level programming languages. Being all language-nazi and saying "only C++" or "only C" or only java or python or Mono isn't doing anybody any favors.
Posted May 2, 2009 21:19 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (26 responses)
You left out the word "easily": "Easily take a C# program and rewrite it in C++." Remember that Gnote is a project ported by one guy in the free time he has while unemployed, and he says it wasn't difficult. From the blog link I posted earlier:
"It is actually not that hard, just a lot of work to do manually because there is over a dozen of thousands of lines of code."
I also found it amusing to discover elsewhere in this thread that Beagle was dropped from the default Fedora installation due to hard to debug memory leaks. Doesn't that contradict one of the main presentation bullet points for the advantages of managed languages, and the alleged resulting productivity boost?
Mono may have its place. But is certainly not the magic bullet that some make it out to be. It's another language and set of libraries that doesn't seem to have all that much on other existing languages and libraries, despite what Miguel and Novell would like for people to think. Although from an empirical standpoint, it does seem to result in bigger, hungrier, more sluggish applications than most others.
I should mention that I administer XDMCP servers. When someone says an app is using 20MB, most people can probably just blow that off. But I automatically do a mental calculation of the impact of having a hundred of those things running.
Also, I should probably elaborate upon just what I think Mono's place should be. I think of it somewhat as I think of Samba. It's good to have the compatibility. I wish we didn't need it. But I'm glad we have it for those developers migrating or porting from Windows. However, I don't like seeing it used for things like Tomboy and F-Spot. And I absolutely cringe at seeing it used in an infrastructure role in the form of Beagle. My concrete reasons are that it's wasteful, slow, and clunky.
But I will also admit to being somewhat wary of it due to its origins, despite all the reassurances. And it is, of course, important to distinguish between the concrete technical reasons not to like it, and the "I feel like I'm standing next to a pit viper" reasons, which is why I mention this.
Posted May 3, 2009 0:02 UTC (Sun)
by JoeBuck (subscriber, #2330)
[Link] (23 responses)
On the other hand, I verified with valgrind that gnote is a leaky C++ program. The developer might want to check that; just create and delete a couple of notes, and there are leaks.
Posted May 3, 2009 1:28 UTC (Sun)
by sbergman27 (guest, #10767)
[Link] (21 responses)
Well, maybe this is a leak, and maybe its just horrific memory usage. But I just installed Tomboy. Started it. Cleared the "start here" default note, and restarted Tomboy. And added 10 notes, one by one. Each one simply said "testing".
Shared memory started at 19M and remained constant throughout the test.
RSS was as follows:
Note# RSS
Incredulous, I added another 10. At the end of the 20th note, RSS was up to 168M! Tomboy starts out using about as much memory as Firefox on start, and then sucks up 7MB for each instance of storing the word "testing" in a note. I find this incredible. Far worse then I had thought previously. 168M to store 140 bytes. Maybe its the unicode...
Could you please run that test with Gnote and post the results? I'm curious how it compares.
Posted May 3, 2009 4:07 UTC (Sun)
by JoeBuck (subscriber, #2330)
[Link] (8 responses)
The leaks I mentioned don't seem to be very large.
By contrast, an instance of Emacs visiting ten files is only 18m. Yet people still claim that Emacs is a bloated program.
Posted May 3, 2009 4:41 UTC (Sun)
by sbergman27 (guest, #10767)
[Link] (6 responses)
Virtual memory size? That's completely useless. What is the RSS size? (Strictly speaking you should turn off swap to take that measurement, but if you have plenty of memory it shouldn't make much, if any, difference.
Just for reference, the virtual memory size for Tomboy starts out at 343M and increases to 439M with 10 notes.
Posted May 3, 2009 6:10 UTC (Sun)
by JoeBuck (subscriber, #2330)
[Link] (5 responses)
Posted May 3, 2009 12:55 UTC (Sun)
by sbergman27 (guest, #10767)
[Link] (4 responses)
To get the "real" unique memory usage for the process, you can (with the swap turned off) subtract the shared column from the rss column. The smem utility, featured a few days ago here on LWN, can show other interesting things, like proportional set size.
Sometimes I think that the authors of "top" had a special conference to determine how to present memory information in the most misleading way possible, and then wrote "top" based upon the results. Many people do think that the virtual size actually means something. And most new users seem to think that Linux is a sort of monster black hole of memory leakage, since no matter what they are doing, it sucks up all available memory until there is almost no free memory left. Htop is, at least, better.
Posted May 3, 2009 17:12 UTC (Sun)
by hppnq (guest, #14462)
[Link] (3 responses)
Posted May 3, 2009 18:38 UTC (Sun)
by arjan (subscriber, #36785)
[Link] (2 responses)
memuse is a small simple app that does a reasonably good job of showing the "real" memory cost of an application; it accounts the cost of a shared library as divided by the number of users etc etc....
Posted May 4, 2009 8:13 UTC (Mon)
by nhippi (subscriber, #34640)
[Link]
awk '/Pss:/{sum+=$2}END{print sum "kB"}' /proc/$pid/smaps
This makes one wonder why ps/top doesn't support showing Pss themself.
The library section of output appears to be quite short, not showing for example libc or libX11.
Posted May 10, 2009 23:26 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
Trouble with that idea is that it depends sensitively on the other stuff that is running at the moment. E.g., having no or 20 processes also using
Posted May 4, 2009 4:19 UTC (Mon)
by jordanb (guest, #45668)
[Link]
That may pose some sort of correlation to Wirth's Law: if you software is considered bloated, all you have to do is wait a bit and someone will come along and blow you away by an order of magnitude.
Posted May 3, 2009 17:59 UTC (Sun)
by drag (guest, #31333)
[Link] (3 responses)
About 5-10 megs per note. The memory usage doesn't go away when you close the notes out. If you restart it then it's fine.
the only thing that I can think of is if it's not a bug (which it does seem very much like a memory leak) is that we both have excessive amounts of RAM and the garbage collecting for Mono isn't getting triggered to reclaim those objects. But I don't know Mono or C# enough to really know what is going on.
It does seem very horrible.
Memory leaks are quite possible with languages like Python or C#...
At least in python you are not allowed to destroy objects in memory directly. It's possible, but it would require wizardry. So what happens is that when you create a object and reference it to a variable name it will stay in existance as long as it has a single reference. Usually people create variables in loops and functions so that the scope of variable is short-lived and the object loses it's reference and is ready to be garbage collecting.
However if you are creating lots of object in a dynamic manner and your using them in a global scope or long-running loop (like the main loop) or whatever then you need to be careful that when your finished with them that either you void out the reference or 'del' the reference. Otherwise they'll just build up and that is were you get your leak.
Also, for good performance, you generally try to avoid invoking the garbage collector as much as possible. So you try to reuse objects or reduce the amounts of objects you create. If your always creating objects all over the place then memory usage will go up and in order to counter that the garbage collection system will be invoked rather often. In long-running programs garbage collecting can take up a singificant amount of processor time if your not careful.
That sort of thing.
But it's deceiving because normally people don't think like that in Python or whatnot. That sort of stuff is usually taken care of automatically so niave programmers will get burned by it.
High level languages are certainly no substitute for skill or knowledge... I think that understanding things like C and memory management is going to be required for the best effective programming in C# or Python or whatever. To get the best out of something like Python you really do need to understand what is happenning under the skin... I don't think that Mono would be any different.
Posted May 3, 2009 19:33 UTC (Sun)
by sbergman27 (guest, #10767)
[Link] (2 responses)
Meanwhile, Tomboy has either a bug or a "feature" which causes it to suck up 32M for doing nothing. And another 7M per note for doing the one trivially simple thing that a sticky note program is supposed to do.
Furthermore, if it is a "feature". i.e. if it is just avoiding garbage collection for performance purposes, as you suggest... well, wasn't one of the central points of this article that Tomboy was annoyingly slow? And the whole idea of "performance optimization" for a trivial sticky note app is absolutely ludicrous in the first place.
If it's a memory leak, then after however many years Tomboy has been around, there is an unbelievably huge and gaping memory leak in the code path for the one very simple thing that a sticky note app is supposed to do: create sticky notes.
Tomboy may or may not be representative of Mono's power. But it sure as hell isn't looking like a very good demonstration of Mono's amazing coolness.
Posted May 3, 2009 19:56 UTC (Sun)
by drag (guest, #31333)
[Link] (1 responses)
To make it very useful it needs to look and behave simply as far as the UI is concerned, but it's quite a complex task.
But ya things are not looking good for the Mono.
Posted May 4, 2009 12:25 UTC (Mon)
by johill (subscriber, #25196)
[Link]
Although now fixed, it will take a very long time to trickle down to distros and makes mono suck a lot of power.
Posted May 7, 2009 10:05 UTC (Thu)
by epa (subscriber, #39769)
[Link] (7 responses)
Posted May 7, 2009 20:47 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (6 responses)
And it is people like you that got us into the situation where a five year old PC can't run a current Linux distro well. So much for being a viable option for old, obsolete low spec hardware, and there goes the 3rd world.
And it is people like you that have probably, in the end, cost us the netbook and smartphone battle. You see, in some use cases it isn't a question of the cost of more RAM, it is the power consumption. Keeping gigs of RAM alive in a smartphone isn't currently possible and it kills battery life like crazy in a netbook.
Time for unpleasant truth time. Put (your favorite linux distro) and XP on a netbook. Which one boots faster? Which one logs in faster? Which one posts the start menu faster (with icons). Odds are XP will win one or more of those races. We got fat dumb and stupid, thats what happened. It wasn't always like this, I remember when Linux was lean and fast. To the people who wanted to make Linux 'just like Windows' all I have to say is Congratulations, you succeeded.
Now imagine that we would have had the sense years ago to look at a clock applet chewing through more RAM than you needed to run a complete UNIX environment in and said , "That is insane!" I can promise you Linksys wouldn't have had to toss Linux off their WRT line for being too fat. We would totally OWN the netbook and smartphone space.
Posted May 7, 2009 22:54 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
(And that's non-ECCRAM costs. If you care about your data, with modern RAM
Posted May 8, 2009 17:14 UTC (Fri)
by epa (subscriber, #39769)
[Link]
Posted May 7, 2009 23:08 UTC (Thu)
by dlang (guest, #313)
[Link]
it's still possible to run linux on low-spec systems, but you aren't going to run Gnome or KDE (or openoffice or firefox) and be at all happy.
if you have a server-type application that doesn't need this, or are willing to do your own GUI stuff (a media box for example), linux can still do the job just fine.
but if you try to install Red Hat, Suse or Ubuntu on the system and start from there you have two strikes against you when you start (Debian isn't as bad right now, but it's also not nearly as good as it used to be)
it's not just that packages are larger than they used to be, it's that many more things have been declared 'essential' that didn't used to be.
Posted May 8, 2009 17:27 UTC (Fri)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted May 11, 2009 9:36 UTC (Mon)
by etienne_lorrain@yahoo.fr (guest, #38022)
[Link] (1 responses)
Posted May 21, 2009 17:08 UTC (Thu)
by epa (subscriber, #39769)
[Link]
Posted May 3, 2009 16:58 UTC (Sun)
by alankila (guest, #47141)
[Link]
Mono has a compacting collector, last time I looked, but it still wasn't used by default due to some problems that seem esoteric enough to not warrant going into here...
Posted May 3, 2009 17:25 UTC (Sun)
by dmarti (subscriber, #11625)
[Link] (1 responses)
git log | grep ^Author | sort -u | wc -l
Posted May 3, 2009 17:30 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 3, 2009 20:27 UTC (Sun)
by njs (subscriber, #40338)
[Link]
This comment is somewhat misleading. The git core was written in C from the start (but then, C is Linus's HLL). It outperformed contemporary VCSes because it took existing design work from systems like BK and Monotone and reimplemented them with a primary focus on speed. (So in that sense, it's more like the post-design optimization phase of your story.) The stuff written in high-level languages was the handy tools and UI stuff around the core, and there your story makes more sense -- quick iteration lets a thousand flowers bloom, people figure out what sort of UI is most useful, and that gets reimplemented in C for portability and ease of maintenance.
Posted May 3, 2009 14:33 UTC (Sun)
by jamesh (guest, #1159)
[Link]
I didn't say that C#/Mono is better than C++: I said that the development of GNote skipped certain development steps so can't really be used to say if one is better than the other.
When designing an application, there is often an iterative process of implementing a feature, testing it and then revising it (either based on your own experiences or external user testing). This often requires the ability to refactor the code, so is an area where the productivity advantages of one system over another matter.
But none of this has happened (yet) with GNote because it is currently just a translation of an existing program. Perhaps you'll get some data as the two projects diverge.
> BTW, just an unrelated note of explanation here. I haven't commented on
I haven't said that this kind of fork/translation is wrong either. I'm just saying that I don't think this pair of projects supports the position you're pushing. Perhaps Beagle vs. Tracker does, but I think you'd need to consider a much larger number of projects in order to say whether C#/Mono increases developer productivity.
Posted May 3, 2009 3:37 UTC (Sun)
by sitaram (guest, #5959)
[Link] (17 responses)
I didn't even know all this... love it, especially the shell script part.
PS: having once written a ticket tracking system in the korn shell on a Sequent Unix many (too many) years ago, and having my own mini "photo classification" app using shell + "xli", I can quite imagine that happening. (Meaning, I don't take it as an exaggerated joke)
Posted May 3, 2009 9:26 UTC (Sun)
by man_ls (guest, #15091)
[Link] (16 responses)
Anyway his point about Mono productivity is very real; I don't know why people are disregarding it so easily. If you could rewrite a Cocoa (Mac OS X dev environment) in C++ just like this, it would mean that the touted advantage of the Cocoa system libraries was not so important. As it stands it seems that the Mono system libraries do not make a big difference from C++ plus GTK, and that is big news.
Posted May 3, 2009 9:58 UTC (Sun)
by patrick_g (subscriber, #44470)
[Link] (4 responses)
Posted May 3, 2009 15:11 UTC (Sun)
by grantingram (guest, #18390)
[Link] (3 responses)
To be fair to the developers of f-spot it does seem to me to be bit more a complete photo management application than gthumb. What I mean is f-spot has:
Whereas I get the impression that the gthumb developers were intent on making an application to look at pictures on your hard drive. Of course f-spot also features:
I'm not intending to start some sort of holy war between photo storage application supporters but they seem to me to have slightly different goals in mind and one is not a drop in replacement for another.
Posted May 3, 2009 15:30 UTC (Sun)
by sbergman27 (guest, #10767)
[Link] (2 responses)
Perhaps if current unemployment rates persist we'll get a C++ g-spot?
Posted May 3, 2009 15:56 UTC (Sun)
by ms (subscriber, #41272)
[Link] (1 responses)
Posted May 4, 2009 2:42 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link]
Posted May 3, 2009 10:26 UTC (Sun)
by sitaram (guest, #5959)
[Link] (4 responses)
I've been using such a shell script (my photo handling needs are somewhat complex in terms of where the files go, and how I want to recognise something that has already been downloaded, etc), since about 2006.
If you meant shell literally as in "nothing but bash, no perl, no sed, no add-on tools [like gphoto2 in this case]", then you are right, it cannot be done.
But when most people say "do it in shell" they do pre-suppose a bit of this sort of stuff.
Even so, I'm not necessarily saying every nuance of f-spot can be done. But I bet the bulk of it can. Maybe a little perl-Tk or some Qt binding for a bit of GUI "cream on top".
Posted May 3, 2009 10:46 UTC (Sun)
by man_ls (guest, #15091)
[Link] (3 responses)
That doesn't show a preview of every picture on the camera, so there is still some work to be done. Any takers? :D
Posted May 3, 2009 12:33 UTC (Sun)
by sitaram (guest, #5959)
[Link] (2 responses)
Perhaps I should combine these two scripts :-)
Posted May 3, 2009 17:27 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted May 3, 2009 18:55 UTC (Sun)
by sitaram (guest, #5959)
[Link]
But right now these two scripts together are barely a couple hundred lines of shell, completely tailored to my specific needs -- my preferred workflow is more akin to a "PIM sync" (like say jpilot) for a camera than a typical photo app!
And while I'm sure the basic stuff is doable "in shell", it won't be pretty (hey that was not in the original discussion so I'm safe!)
So you see there's a bit of a gap there :-) Still, I guess I'll give it a shot, just for kicks...
Posted May 7, 2009 21:09 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (5 responses)
I see that as more of a bug than a feature. Since I have never encountered a digital camera made since the VERY early days (i.e. one megapixel or less) that didn't store the images as files on a FAT/VFAT file system and exported that as a USB mass storage device, why would F-Spot spend so much effort reinventing a perfectly good wheel?
I see that sort of thing as needless bloat taking up space and harboring vast potential for bugs and security problems in little used and likely poorly audited code.
Posted May 7, 2009 22:31 UTC (Thu)
by spitzak (guest, #4593)
[Link]
I was relying on F-spot renaming the files to -1.JPG when there was a collision in order to get rid of duplicates (why they can't remove even the most obvious duplicates is another question!). I now had lots of .jpg files as well. Trying to clean up this mess and I deleted a lot of non-duplicate .jpg files.
They certainly should *not* be doing this at all. Mount the damn disk and maybe detect and offer to import using the same code as before! Even the user-friendly OS/X mounts the disk and the user has to eject it.
Posted May 8, 2009 4:31 UTC (Fri)
by sitaram (guest, #5959)
[Link]
Posted May 8, 2009 16:56 UTC (Fri)
by aigarius (subscriber, #7329)
[Link] (2 responses)
Also there is a big bonus of PTP - you can request the camera to get all thumbnails of all photos on the camera and get it in a few seconds. Then you can select which exactly photos do you want to download from the camera.
Posted May 8, 2009 17:09 UTC (Fri)
by martinfick (subscriber, #4455)
[Link] (1 responses)
Posted May 8, 2009 18:29 UTC (Fri)
by man_ls (guest, #15091)
[Link]
Posted May 1, 2009 21:36 UTC (Fri)
by butlerm (subscriber, #13312)
[Link]
In the long run, rather than porting C# projects to C++, it would probably be
Posted May 1, 2009 21:49 UTC (Fri)
by leoc (guest, #39773)
[Link] (1 responses)
I just yum install'd it on my F10 box (gnote 0.2.0-2.fc10) and it does dismiss notes when you press escape. On the other hand, it crashed hard when I clicked "delete" on an example note...
Posted May 2, 2009 7:12 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
https://admin.fedoraproject.org/updates/gnote-0.3.0-1.fc10
It fixes a number of crashes. If it hasn't fixed the problem you have mentioned, do file a bug report.
Posted May 1, 2009 22:44 UTC (Fri)
by oever (guest, #987)
[Link] (2 responses)
Posted May 3, 2009 15:12 UTC (Sun)
by man_ls (guest, #15091)
[Link] (1 responses)
A similar but quite longer story could be told of human (natural) languages: even though there are many similarities, nobody has been able to find a convincing common ancestry for them all. Again, see the interesting Wikipedia article. However, to the people of a certain region the history of the Tower of Babel would seem very familiar: a common language rapidly deteriorates into a family of languages with a common ancestry, in the case of Latin within a few centuries. Suddenly people do not understand each other anymore.
Posted May 7, 2009 16:05 UTC (Thu)
by leoc (guest, #39773)
[Link]
Posted May 2, 2009 6:43 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
https://www.redhat.com/archives/fedora-desktop-list/2009-...
It does support a number of plugins, a applet for GNOME and is getting to be quite a good replacement. Try it out.
Posted May 3, 2009 15:49 UTC (Sun)
by ms (subscriber, #41272)
[Link] (17 responses)
What I fear this smacks of is a general dislike of hosted languages and even just a fear of more sophisticated languages. This seems to be a "stick your head in the sand" issue. Yes, there is definitely value in knowing how to write assembly, how to write in C if you're doing low level work, and what the constraints and issues are with such languages. But really, come on, the world has moved on. It's 40 years later. Now sure, I wouldn't claim the Java or .Net platforms are the most efficient and highly tuned platforms in the world - it is well known, for example, that the Sun JVM contains 3 different implementations of regular expressions because they were close to the deadline and different developers just stuck in what they needed - deadlines affect code quality for _all_ programmers. But, the advantages of hosted platforms (security, speed of development, portability, richness of libraries) really are worth it. I fear this audience of, it would seem, die-hard kernel C hackers are unlikely ever to be convinced of the added value, but the simple fact is, 99% of the world's programmers are rubbish. Would you rather give them C, where their ignorance makes them unproductive and exposes massive security issues, or Java/.Net/Mono where so much of the need to think is taken away? Saying they shouldn't be programming in the first place isn't an answer. I wouldn't claim this leads to better programmers or better programs, but I would claim it increases productivity.
Yes, I can write C when I need to, but I wouldn't ever claim to be an experienced C programmer. I'm much happier with Haskell / Erlang / Scala, because the sorts of applications I write don't become better applications when I have to remember when to call "free".
Posted May 4, 2009 12:29 UTC (Mon)
by liljencrantz (guest, #28458)
[Link] (10 responses)
I believe that the problems with high level languages are fixable, and that higher level languages are the way ahead, but it is definitely a bumpy ride.
Posted May 4, 2009 12:44 UTC (Mon)
by ms (subscriber, #41272)
[Link] (3 responses)
I have to say I don't enormously understand people getting upset with obscene memory usage, so long as it's not leaky. RAM's pretty cheap, and a standard box is 4GB RAM these days. Even firefox, which I have with about 80 tabs open is currently only eating 25% of that right now. Of course, the situation is different on a mobile or otherwise constrained device, but then again, for such a device you probably wouldn't aim for so many features. The issue about leaky is key though - a good programmer need not spend too much thought ensuring their program doesn't leak memory when writing in higher-level languages. I've seen many good programmers lose weeks trying to track down leaks in C++ programs.
Posted May 4, 2009 16:29 UTC (Mon)
by sbergman27 (guest, #10767)
[Link]
And my largest XDMCP/NX server runs 60 Gnome desktops. 32MB + 7MB per note represents 2G just to have the program open and almost 0.5G per user*note. If each user had 10 notes, I'd be looking at 6G of memory use. The current server maxes out at 12G. Your "My Computer" style of thinking, applied broadly, would absolutely *cripple* Linux on the corporate desktop. Fortunately, Tomboy's functionality is completely inconsequential, and there are saner options available to people who do have some need for it.
Posted May 7, 2009 16:53 UTC (Thu)
by anton (subscriber, #25547)
[Link]
I don't understand your obsession with memory leaks. Some programs
such as OS kernels that are intended to run forever certainly should
not be leaky, but for, say, Even for a long-lived note-taking program, if it, e.g., leaked all
the strings that the user inputs that would be a small amount of
leakage compared to the obscene memory use of Tomboy; I doubt that the
user creates and deletes notes containing MBs of strings.
Moreover, I have seen programs that just get worse by trying to
avoid memory leaks. E.g., Netscape 4.72 grew quite a lot over its
lifetime (very much like a leaking program), but when it was paged out
and I wanted to exit from it, it would take several minutes to page in
all that memory, apparently because it wanted to free it so that some
leakage-detecting tool would be satisfied. It would be more
responsive and reduce memory pressure to just exit without freeing all
the memory explicitly.
Posted May 7, 2009 18:15 UTC (Thu)
by jordanb (guest, #45668)
[Link]
"I don't understand why everyone's getting upset that the reservoir is running dry, so long as nobody is letting the faucet drip."
Posted May 4, 2009 15:08 UTC (Mon)
by sbergman27 (guest, #10767)
[Link] (5 responses)
You can't just dump "web frameworks" all into one performance category.
Posted May 4, 2009 22:01 UTC (Mon)
by liljencrantz (guest, #28458)
[Link] (4 responses)
But on the other hand, not all code needs to be fast. I've written Ruby and Python applications and enjoyed the powerful and convenient features Rails has to offer.
I guess one has to evaluate the performance requirements of each new project, and use as high level a language as possible.
Posted May 5, 2009 20:02 UTC (Tue)
by salimma (subscriber, #34460)
[Link] (3 responses)
Posted May 5, 2009 20:12 UTC (Tue)
by jordanb (guest, #45668)
[Link] (1 responses)
Posted May 6, 2009 3:30 UTC (Wed)
by shmget (guest, #58347)
[Link]
Yes writing a god string library in C is some work, but you have to do that only once.
"there's the problems with butchering any string that contains a NULL character."
So you are left with dealing with 'string' that actually contain the character NULL... and quite frankly that is practically irrelevant.
Furthermore, a good String library will keep track of size -- without using the C zero-terminated convention -- for performance and memory management reason, so even the irrelevant 'problem' of NULL in a string is actually covered as a side effect....
The whole 'memory management is hard' theme is a red herring. Good design is hard, good coding is hard, yes... but memory management is really a question of disciple and habit, and after a while if become second nature.
Posted May 7, 2009 20:21 UTC (Thu)
by liljencrantz (guest, #28458)
[Link]
Posted May 4, 2009 14:29 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (4 responses)
Posted May 5, 2009 20:44 UTC (Tue)
by ms (subscriber, #41272)
[Link] (3 responses)
No, and I've no idea how you managed to reach that conclusion. I listed several substantial advantages to modern languages over ancient languages, as have you. Gnote didn't have to do any design. It's a clone. With no disrespect intended to the author, it's a mechanised process to take a program in one language and translate it to another language. This is what compilers do. I suspect that whilst Gnote is faster, it will be less secure and will leak memory. It'll also be harder to debug when it crashes, and its code base will end up bigger and will reimplement features and properties that .Net/Mono gives you. The code will end up less maintainable and degrade in quality faster.
Posted May 5, 2009 22:42 UTC (Tue)
by jordanb (guest, #45668)
[Link] (1 responses)
None of my complaints regarding C strings applies to C++ using the STL. C++ STL strings are modern and powerful. I don't know if gnote uses them or not (a lot of people write C code in C++ for some reason) but if it does, complaints about "obsolete languages" aren't valid. C++ is a messy monster but all the modern functionality *IS* there.
Posted May 7, 2009 7:01 UTC (Thu)
by alex (subscriber, #1355)
[Link]
Posted May 7, 2009 13:38 UTC (Thu)
by dgm (subscriber, #49227)
[Link]
Posted May 28, 2009 19:03 UTC (Thu)
by togga (subscriber, #53103)
[Link]
"security"
"speed of development"
"portability"
"richness of libraries"
Posted May 4, 2009 12:32 UTC (Mon)
by cate (subscriber, #1359)
[Link] (3 responses)
Posted May 4, 2009 13:31 UTC (Mon)
by corbet (editor, #1)
[Link] (1 responses)
Posted May 6, 2009 14:55 UTC (Wed)
by GreyWizard (guest, #1026)
[Link]
Posted May 4, 2009 13:50 UTC (Mon)
by jamesh (guest, #1159)
[Link]
Tomboy, Gnote, and the limits of forks
Reimplementations for Android
For example, if Android becomes a popular netbook OS, the constraints of the development environment make it that much more likely that you see application level functionality that currently exists in python and mono languages rewritten for Android's java platform to fill up the Android online apps store.
Reimplementations for Android
Reimplementations for Android (diversity)
Reimplementations for Android (diversity)
from reality: there have been high quality bindings for Qt and KDE to
other languages for C++ for as long as there has been the claim that Gnome
and GTK were the place to go for language bindings.
Reimplementations for Android
little niche of the linux enthusiast world that we live in
time. I recently started fiddling with a project using ruby, a nice
language if I may say so. Thinking that the gui bindings were working
fine, until I tried them. Switched to python, another nice language but
seemingly better binding support for the gui library that I use (qt).
maintained and not working right this moment for the latest qt. Pyqt works
just fine.
natural monopoly will prevail. Hopefully not too efficiently.
Reimplementations for Android
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
Hey! Who are you calling old?!
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
No way to resist
Hey! Who are you calling old?!
Tomboy, Gnote, and the limits of forks
Our editor has enough with being grumpy, as to also suffer from old age. Also, it is not PostIt (which is a trademark) but computerized note-taking. Speaking of PostIt, I remember actually seeing some note-taking application by 3Com with the official PostIt trademark, but apparently it didn't reach too many people.
Grumpy editor
Grumpy editor
The history of note taking applications
> the MacOS application has hyperlinking or not.
I actually think that there's an advantage in having more than one implementation, and requiring those implementations to interoperate (by reading each other's data). It forces file formats to be documented in some other form beyond the source code.
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
Great news
Great news
Great news
Great news
sudo apt-get install this...
sudo apt-get install this...
trying to fix it
Escape to close a window?
Escape to close a window?
Great news
Great news
Tracker is faster, but it doesn't index or pull metadata as nearly as well, or support as many formats as Beagle does.
"""
If your comparing Tracker vs Beagle you might as well do in slocate vs Beagle for all the relevence of it.
"""
Great news
http://projects.gnome.org/tracker/
vs
http://beagle-project.org/Supported_Filetypes
Great news
It probably has more to do with the fact that tracker is less invasive and uses less resources, and was adopted by Gnome, then any sort of feature parity.
"""
Great news
Great news
Beagle was having a number of hard to debug memory leaks and Tracker was not mature enough yet.
"""
Great news
default.
Great news
Great news
Great news
Great news
A guy even wrote a book about how Garbage Collection was the best thing since slice bread, and even taking bet that eventually the Linux Kernel will be rewritten ... wait for it... in C#!!!!
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." Albert Einstein.
Great news
Great news
We are talking with the Tracker people to use this Strigi functionality which available from the library libstreamanalyzer.
Refactoring
Great news
Great news
see any issue. This community obsesses on licensing details. And the license(s) used by Tomboy specifically allow for all of this. In fact, the licenses range from "do whatever you want" to going into painstaking detail to ensure that everyone is forever allowed to do exactly what Hubert did. GPLv2 even gets specific about allowing conversion to GPLv3. So what could possibly be considered a problem? I guess maybe that some in the Tomboy camp would have liked to have used a more closed license. It must be disconcerting for them to see a new, leaner, competitor, without the Mono stigma, but with Tomboy's feature set, rise up from out of nowhere and start getting positive publicity almost from day one.
Great news
Great news
So since Mono was written in C (or C++, I don't know the details) then the fact that somebody is able to take a C# program and rewrite it in C++ is of zero surprise.
"""
Languages that use garbage collection are free from one source of memory leaks; they can collect an object that is no longer reachable by any pointer or reference. However, if the programmer uses this feature to get sloppy, he/she often winds up with ever-growing memory because objects that are no longer needed are still linked into a massive, confusing data structure, and the result can be that the program grows and grows, failing to free unneeded storage, just like a leaky C++ program.
Memory leaks in managed languages
Memory leaks in managed languages
On the other hand, I verified with valgrind that gnote is a leaky C++ program.
"""
0 32M
1 43M
2 50M
3 57M
4 63M
5 69M
6 75M
7 82M
8 88M
9 94M
10 101M
It looks quite similar; as reported by top, the virtual memory size for gnote rises to 110m with ten notes displayed. My guess is that the memory is mostly used by the gtk+ objects, which are probably just the same for the two programs.
Memory leaks in managed languages
Memory leaks in managed languages
the virtual memory size for gnote rises to 110m with ten notes displayed
"""
I get 53M for RSS with ten notes displayed.
Memory leaks in managed languages
Memory leaks in managed languages
The virtual memory usage as reported by top and ps includes shared libraries, among other things, which is why the numbers do not add up to a necessarily meaningful number. No conspiracy here. ;-)
Memory leaks in managed languages
Accounting memory usage
Accounting memory usage
Accounting memory usage
glibc at the moment makes quite a difference "on average".
Memory leaks in managed languages
Memory leaks in managed languages
Memory leaks in managed languages
Memory leaks in managed languages
Memory leaks in managed languages
Memory leaks in managed languages
Memory leaks in managed languages
> it uses seven cents of memory?
Memory leaks in managed languages
letter? A hundred words costs ten dollars?!
volumes, you really should get ECCRAM, even if it is slower.)
Memory leaks in managed languages
A hundred words costs ten dollars?!
Obviously not - I doubt the memory usage for a hundred-word note would be significantly more than a note saying 'hello'. It would still use about seven cents' worth of memory, or perhaps ten cents.
Memory leaks in managed languages
Even a netbook these days comes with 512 megs of RAM as standard, and happily runs big applications such as Firefox and Openoffice (they are both installed as standard on my year-old Acer). I appreciate the sentiment you express that everything has gotten slower and bloatier, but really, this is a standard old-timer's complaint that was just as valid in 1999, 1989 or even 1979 as it is now. If there is a need to make the system faster and less power-hungry, then as with optimizing any software, it's best done by profiling to find the high-priority fixes, not by microoptimizing based on guesses or moral outrage about a particular app's memory usage.
Memory leaks in managed languages
Now imagine that we would have had the sense years ago to look at a clock applet chewing through more RAM than you needed to run a complete UNIX environment in and said , "That is insane!"
This was indeed my reaction many years ago when I first saw that xclock used over three megabytes of memory. Yet somehow the trusty old xclock is now considered lean and mean by today's standards.
Memory leaks in managed languages
Cache memory is expensive - that is why processor price vary so much.
In simple words, if a piece of code is completely in the first level cache (code and data), you can consider it done; if it is in the second level cache, it will be done really soon; if it is elsewhere, you will need to wait.
That is independant of the micro-optimisations like number of assembly instructions on a function, but it means you have to take care of the "locality" principle which is the memory cache design principle.
Basically, to write good code, you should not page-in (into the cache) more than what you need, by correctly organising your data (all you will need will be on the same cache lines) and by correctly inlining functions.
Also, to be a "good citizen", you should not completely trash the memory cache just to display the time...
Memory leaks in managed languages
Memory leaks in managed languages
One guy?
18
One guy?
Great news
Great news
> C++/GTK+, as Novell and others like to trumpet, then a C++ programmer
> trying to port a C#/Mono app to C++/GTK+ should start running into
> barriers immediately.
> the topic of this story, about forking, porting others' code to another
> language, and converting between GPL versions, because I absolutely
> don't see any issue.
Great news
I understood that the last part (a F-Spot replacement written in shell) was a desideratum on the part of sbergman27. It has not happened yet, but the author of the post thinks it would be possible and would leave Mono in a very bad situation. I am not so sure that it would be possible, especially written in shell script -- F-Spot imports pictures from cameras directly, and apparently it does not mount the camera as an USB disk; so it needs access to low level system calls. I don't know of any shell utilities that do this.
For the sake of precision
An excellent GTK+ alternative/replacement for F-Spot already exist : http://gthumb.sourceforge.net/
For the sake of precision
f-spot and gthumb
f-spot and gthumb
To be fair to the developers of f-spot it does seem to me to be bit more a complete photo management application than gthumb.
"""
f-spot and gthumb
au contraire, I know a few who can locate their own.
f-spot and gthumb
For the sake of precision
No, you are right: that would nicely fit the task. So there is actually a shell utility that can import pictures, good to know!
For the sake of precision
For the sake of precision
For the sake of precision
For the sake of precision
For the sake of precision
> it does not mount the camera as an USB disk; so it needs access
> to low level system calls.
For the sake of precision
For the sake of precision
http://en.wikipedia.org/wiki/Picture_Transfer_Protocol
For the sake of precision
For the sake of precision
I don't know what type of camera you have, but my several Canon Ixus (an excellent series IMHO) take several minutes to download e.g. a thousand pictures. Some visual confirmation of what you are indeed downloading is nice, at least.
For the sake of precision
Tomboy, Gnote, and the limits of forks
users can bring Tomboy up nearly as fast as the essentially identical C++
port, then something appears to be seriously wrong with the Mono / .NET
architecture.
worthwhile to use something like VMKit and LLVM to compile those projects to
native binaries that run efficiently. Or fix whatever is afflicting Mono, if
that is possible...
Tomboy, Gnote, and the limits of forks
Annoyingly, it does not (unlike Tomboy) dismiss notes when the escape key is hit.
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
It appears that there never was a primordial computer language; many have a common ancestry, but a lot of them have been independently created. See e.g. this chart or Levenez's chart. This one even shares your biblical reference. The Wikipedia article has an interesting reflection of pre-1940 languages.
Babelian reflections
See also Snow Crash.
Babelian reflections
Gnote in Fedora
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
I have to say I don't enormously understand people getting upset with obscene memory usage, so long as it's not leaky. RAM's pretty cheap, and a standard box is 4GB RAM these days.
"""
Obscene memory usage vs. memory leaks
I have to say I don't enormously understand people getting
upset with obscene memory usage, so long as it's not
leaky.
Obscene memory usage is obscene.
ls, obscene memory usage
would certainly be a bigger problem than a memory leak.
Tomboy, Gnote, and the limits of forks
> obscene memory usage, so long as it's not leaky.
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
And no, you do not have to impose silly restriction.
Every Mixed CCSID that I know of take great care to avoid binary 0 in any port of a character. (pure DBCS usually avoid it too, except UTF-16, but then the 'unit of work' is a int16_t not a int8_t)
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
Speaking of sticking the head in the sand!
Suposedly Mono/.NET was to bing: faster development, safer code and near native code speeds (whe JIT-compiled).
Gnote has needed a mere month to get to its actual state, and everybody says it's clearly faster than Tomboy. The question is: is Tomboy any safer than Gnote?
One interesting thing is that, in fact, the Gnote case is just anecdotal evidence. We still need more examples of real world applications ported.
Tomboy, Gnote, and the limits of forks
Tomboy, Gnote, and the limits of forks
STL and Boost I think
Tomboy, Gnote, and the limits of forks
The rest, only time will tell, but it will be interesting to keep a eye on both.
Tomboy, Gnote, and the limits of forks
BS. More dependencies = more to attack
BS. You'll have to solve the same fundamental problems in each language. High level abstractions can and are being made everywhere. The high level platform may look fancy at the beginning, but in the end it only enforces restrictions on you and your "spped of development" deteriorates. If you choose a high level platform, make sure it at least have seemless integration with C [like Python].
BS. Mono apps is portable to .NET platforms only?
Compared to what?
Tomboy, Gnote, and the limits of forks
citation, people can *apply* GPL3, but to relicense need copyright holder.
(see also the last year LWN article about BSD to GPL driver in kernel)
Perhaps my choice of terms was sloppy. That doesn't change the fact that Gnote is distributed under (and covered by) GPLv3 and no other license. It's a de facto relicensing, regardless of what you might want to call it.
Relicensing
One minor clarification: GPLv3+
Tomboy, Gnote, and the limits of forks