Great news
Great news
Posted May 1, 2009 21:21 UTC (Fri) by sbergman27 (guest, #10767)Parent article: Tomboy, Gnote, and the limits of forks
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]
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