Gnot Invented Here
- on 2009-05-02
- Rants
- 62 Comments
A short missive on Gnote, which ties into my last post about bloat.
Gnote is, for those living under a large pile of particularly non-porous rocks, a fork of Tomboy, doing a line-by-line translation of the source into C++. It was announced one month ago today, and has already seen several releases.
Gnote is impressive. No really, The fact that Gnote exists is a testament to the patience of its developer – Mono (which Tomboy uses) was created to remove the pain associated with mangling C or C++, so taking an existing app and going back there is impressive work. It impressed me enough that when I became aware of it, I considered packaging it myself – however, inspection at a source level made me decide I couldn’t support certain practices which I’m not going to go into. That, and several members of the anti-Mono brigade had already accepted Gnote as their shining saviour and done packaging already.
If Debian’s FTP Master determines that Gnote is permissible for inclusion in Debian (I hear FTP Master has been particularly stringent these days in checking copyright) then great. Gnote is unquestionably faster to start up than Tomboy – that’s because Tomboy runs though a JITter and Gnote doesn’t. It doesn’t take a rocket scientist to determine that app startup time is higher on Mono apps than non-Mono apps. We’re not talking much time here – about a second or two tops on my desktop – but for some, that’s significant.
However, I think it’s worth mentioning at this point that those same anti-Mono elements (Moycott Movell, mi’m mooking mat moo) don’t seem to comprehend basic benchmarking technique, and readers should be very wary of their quoted numbers relating to (you guessed it) bloat. Firstly, RAM numbers. The quoted figures are 15.2 MiB versus 5.5 MiB. How true are these numbers? Well, first, let’s look at the RAM consumption here on Ubuntu 9.04 of both apps – Gnote 0.3 and Tomboy 0.14.0 – with a fresh install. 14.2 MiB versus 7.6 MiB. Hm, those numbers don’t add up to what was quoted. I wonder why….. Firstly, Gnote is a C++ app, and as a result, is much more memory hungry on 64-bit architectures like mine than on 32-bit architectures – that accounts for some of the difference.
However, let’s look closer – what functionality exactly is being offered by both apps, out of the box? Gnote comes with 4 add-ins, all enabled: printing, bugzilla links, fixed width, and timestamps. Tomboy has all of these, but ALSO comes with Sticky Notes importing, backlinks, HTML export, Evolution integration, local directory and WebDav synchronization, but NOT the timestamp addin by default. Let’s change Tomboy’s addins to match Gnote, shall we? 14.1 versus 7.6 – Gnote is half as RAM-hungry as Tomboy if you disable two thirds of its abilities. If you don’t want those abilities – e.g. integration into Tasque to-do lists or synchronization to anywhere else, then Gnote is definitely the less “bloated” app. But, just for curiosity’s sake, shall we try another comparison – Gnote with ALL its abilities enabled versus Tomboy with ALL its abilities enabled? 14.5 versus 7.6, with three times the feature set. Three times the features in twice the RAM footprint would, if my sums are correct, make Tomboy the less-bloated app in terms of features-per-meg-of-RAM. If you use those features. And now we’re looking again at defining bloat.
Now, the disk space question. Tomboy and its unique deps take 13.9 MiB of space on a Jaunty install CD. Gnote pulls in 6.3 MiB – so, again, about half the size. These numbers make certain assumptions – for example, that we’re working purely on these packages, and not making hysterical judgements on surrounding frameworks. Ubuntu comes with Mono and GTKmm by default due to other apps, and it’s important when measuring this kind of thing not to impact on other apps. And if you want a clue as to where the space difference comes from? Tomboy comes with documentation in 14 languages, taking 4.4 MiB of disk space; Gnote has 2 languages, taking 1.1 MiB. Don’t do the maths on what that would mean if Gnote had parity on number of languages including documentation, it’ll make you sad. Yet again, we’re into subjective territory over classifying features (such as documentation) as bloat or not. And the only people equipped to do that are the distro packagers who make a decision.
IF Gnote can reach feature parity with Tomboy, and IF it remains smaller on disk and in RAM with those features it currently lacks, and IF it shows a clean bill of health for security and stability over a testing period longer than its one month on this Earth, and IF the desktop team are comfortable switching from an app with an upstream team to a one-man show, and IF the desktop team are comfortable going from an app which innovates to an app which emulates, then I think it’s pretty clear which app makes more sense on the default install CDs. Until then, let’s be sure to compare Gnote and Tomboy using real, verifiable metrics and not hyperbole.
I think the startup difference is partly because of perf problems in
mono.addins and/or ndesk.dbus. Or because tomboy seems to rebuild
the mono.addins registry on every startup:
http://svn.gnome.org/viewvc/tomboy/trunk/Tomboy/AddinManager.cs?revision=2210&view=markup
[reply]
“It doesn’t take a rocket scientist to determine that app startup time is higher on Mono apps than non-Mono apps”
The JIT would app time in the order of a few milliseconds. Definitely not something noticeable. The vast majority of the time difference in startup is due to applications performing completely different tasks before bringing up the main GUI. In this case Tomboy does a lot more work because it has features which require additional processing.
There was an article before about benchmarking a C++ and C# app which do identical work and the C++ app had to be rewritten several times before it could match the C# apps performance. Of course, at that stage the C++ app was completing its work in less time than it took the C# app to launch, but we’re talking < 100ms here. My google foo is failing me, but if i find the article i’ll link it. It was interesting to read.
[reply]
Jonathan Pryor Reply:
May 2nd, 2009 at 7:33 pm
@Alan, You’re looking for Raymond Chen’s memorial classic on how to write and optimize a chinese dictionary lookup program. Rico Mariani helpfully provides links to the entire series at: http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx. The same link also has a C# equivalent to the C++ app.
Alas, he doesn’t have appear to have a post referencing all of the optimizations and analysis he does on his C# code, but his index at http://blogs.msdn.com/ricom/archive/2005/05.aspx does — just read all the Performance Quiz #6 links.
It should be noted that the C# code isn’t ideal, as it runs under .NET 1.1, not 2.0, so it uses P/Invokes to QueryPerformanceCounter()/etc. when System.Diagnostics.Stopwatch would be a more portable solution. (In other words, the code he originally provides isn’t portable to Mono, though it is trivially modified to be portable.) Even so, it ran much faster without additional optimization steps — the original C++ program ran at 1.328s, while the original C# program ran at 0.124s to do the same thing.
It should also be noted that the final optimized C++ code was…fugly. All STL code was removed, replaced instead with lots of direct Win32 code. It is no longer portable to anything other than Windows (for those who consider portability important). It grew progressively larger with each version, eschewing pre-existing libraries for custom-written, faster, code. In short, it would be annoying to mainten.
[reply]
“Ubuntu comes with Mono and GTKmm by default due to other apps”
Yes. But there are only two apps that Mono supports by default in Ubuntu 9.04: F-Spot and Tomboy.
That’s 54MB of patent trap and bloat just *to run* a note taking app (of which there are many) and a camera thingemyjig.
gThumb works just fine for me.
sudo apt-get purge libmono0 mono-common
Save yourself 54MB right there.
Al
[reply]
@The Open Sourcerer, I think you failed to read my post on the topic of bloat. You’re unhappy about libs shared by two apps… How about libs used for ONE app? GTKmm is included ONLY because gnome-system-monitor uses it, to a total of 14.1 meg for the app and lib. Is that bloat for a graphical “top”? Gedit pulls in 16.7 meg – is that bloat for a simple text editor? (hint: yes, Geany is less bloated, but not necessarily a better default).
Again, re-read the two posts – bloat isn’t about disk space used, it’s about resources-per-feature.
As for patent traps, I suggest you take a closer look at Gnote’s source – it reimplements portions of the CLI base libraries in C++ – any patents violated by (for example) DateTime in Mono are just as violated in Gnote’s implementation. I don’t think there’s much point discussing the topic further with you, as I can’t see it going anywhere productive.
The best app for a task may cost a little more in terms of disk space. The question is the balance between features and space. This was covered in my post about bloat. Where frameworks are concerned, there’s a law of bulk – as it stands, Tomboy + F-Spot (+ Mono) add up to 26 meg each on average for those 2 apps. Switch to Banshee, and the average drops to 22 meg each. Add, say, Blam (RSS client) and it drops to 20 meg each, despite pulling an entire HTML rendering engine (WebKit). The per-app footprint shrinks. By your logic, No Java app could ever make it in – as the app would be scuppered by the hundred meg of OpenJDK “bloat”.
[reply]
Dear Joseph,
I skipped most of the post, as I didn’t find the endless stream of number to match my interest. There was something that caught my attention though:
“If Debian’s FTP Master determines that Gnote is permissible for inclusion in Debian (I hear FTP Master has been particularly stringent these days in checking copyright) then great.”
Gnote has no known copyright issues. It adheres strictly to the original license of the code, and keeps all the copyright assertion lines and license statements that were in the original Tomboy.
The GNOME project acknowledges this by hosting and distributing the Gnote source code.
The Tomboy authors further confirm this by acknowledging Gnote existance, as well as criticizing many things they don’t like (which is perfectly legitimate), and not bringing up anything about those supposed “copyright issues”.
The Fedora project further confirms this by including Gnote in Fedora 10 and 11.
If you found real copyright issues in Gnote which you haven’t yet specified, I can’t tell. But as far as things stand now, Gnote is in a perfectly sane shape with regard to copyright/licensing.
[reply]
directhex Reply:
May 2nd, 2009 at 6:27 pm
@Robert Millan, sanity and clarity aren’t necessarily the same thing. I hear Xulrunner was rejected recently for being too vague in its copyright file, even though I doubt anyone doubts that the overall result is pretty Free. Generally, the best advice I can give is to use the CopyrightFormat proposal, and make it crystal clear what files have what licensing/copyright. At the very least I’d suggest that since Gnote is GPLv3, you should point people to /usr/share/common-licenses/GPL-3 not /usr/share/common-licenses/GPL (regardless of the current symlink)
[reply]
Robert Millan Reply:
May 2nd, 2009 at 6:44 pm
> Generally, the best advice I can give is to use the CopyrightFormat proposal, and make it crystal clear what files have what licensing/copyright.
Sounds interesting. I never looked at that proposal in detail, maybe this will be a good occasion.
> At the very least I’d suggest that since Gnote is GPLv3, you should point people to /usr/share/common-licenses/GPL-3 not /usr/share/common-licenses/GPL (regardless of the current symlink)
Gnote is GPLv3-or-later, so it can always be distributed under the terms of the latest version of the GPL, whichever that is. Users are implicitly allowed to use the latest terms as soon as a new GPL is released, but when the symlink is updated, indicating the new license has been found acceptable for Debian, for me it is a good indication that it can be recommended to them.
Oh, and I’m lazy. I’d rather save a few seconds every X years by not having to edit debian/copyright :-P
[reply]
Robert Millan Reply:
May 2nd, 2009 at 6:47 pm
@Robert Millan, btw, I really dislike when the interblags turns my pretty, clean, pure-ASCII smileys into ugly, pixelated stuff. Talk about bloat, why spend 176 bytes when you can do it in 3.
[reply]
directhex Reply:
May 2nd, 2009 at 7:01 pm
@Robert Millan, globally disabled, just for you. Let it not be said that I’m uncooperative
[reply]
:-)
[reply]
What’s interesting, is… will distros want to include an application that needs to catchup to the original (which is already included)? Is there any point in that?
At some point tomboy is bound to use some feature of mono/.net that depends on a big part of the framework and will be either skipped in gnote, or will take them 1-2 months (of writing a supporting library) just to support that 1 line of code. If they don’t add any value to the application, but we have to wait for features, then who will want to use it? Well, apart from people who want to use it just because it’s not c#…
OTOH, if anything unique gets added to gnote, I think it will be ported to tomboy ASAP. It might be a funny day when that happens…
[reply]
directhex Reply:
May 2nd, 2009 at 9:44 pm
Features CANNOT be ported back from Gnote – Gnote is GPLv3, and is only compatible with LGPL2 in one direction. I suspect this was 101% intentional.
[reply]
Robert Millan Reply:
May 3rd, 2009 at 12:27 am
@directhex, this is not accurate. LGPL code can be merged with GPL code. However, if Tomboy developers need to avoid GPL for some reason, they will probably refuse to include any GPL code in their tree. It is their choice, but that doesn’t mean the license prevents them from doing so.
[reply]
directhex Reply:
May 3rd, 2009 at 12:42 am
@Robert Millan, except including one line of GPLv3-licensed source in Tomboy changes the effective license for the entire project. You can ask assorted *BSD developers their feelings on this kind of “generosity” from people absorbing their code into a GPL project like the kernel. You know full well what I meant. GPLv3 + LGPL2 = GPLv3 – hence why the compatibility is “one-way”.
[reply]
Robert Millan Reply:
May 3rd, 2009 at 1:06 pm
@directhex, yes, I know what you meant. But it’s not correct to say they’re forbidden from using GPLed code. It just happens that the copyleft comes with conditions they don’t like. Those conditions were designed to ensure the basic freedoms are passed along in all directions (for example GPLv3 prevents them from selling exclusive patent protection). Though, as I said before, it is their choice to accept them or refuse them. It is their karma, not mine.
[reply]
rgz Reply:
October 8th, 2009 at 3:17 am
That is one funny thing about the “BSD over GPL” crowd.
If BSD code is relicensed as GPL they are *absorbing* it, who wants their \”generosity\”? If it is relicensed as proprietary it’s “fine by me, I just want my code to be free”.
Aaaanyway, you seem to hate Gnote because it’s young and still lacks features and team members, could you cut them some slack? The only thing they are doing to you is *not using mono* you seem to hate people for not using mono.
[reply]
directhex Reply:
October 8th, 2009 at 10:17 am
@rgz, The thing about GPL “absorption” is that when you use BSD, you accept that not everyone will share their changes to your code with you – that’s the “cost” of using that license. However, it’s galling for someone to share their changes with *other people* but not you. Therein lies the difference.
As for Gnote, I hate the way it’s used as a beating stick by people who have an agenda – I’m pretty sure I said multiple times that if it were a superior app, it would make for a better default. If people want to advocate Gnote, they should do so HONESTLY – i.e. honesty regarding functional equivalence, over disk usage, over RAM usage, should be honest and use honest numbers – not the fabrications of agenda-driven liars. If Gnote were “just an app” then it wouldn’t offend – but as a poster child for offensive people, by being marketed as something which it is not, it causes ire.
[reply]
rgz Reply:
October 8th, 2009 at 11:30 pm
@directhex, so
not sharing at all == good
enforced sharing == bad
We are arguing against sharing, right?
[reply]
directhex Reply:
October 9th, 2009 at 12:07 am
@rgz, I’ll attempt to give you a comparison. If it fails to be understood (if not agreed with), then you’re a lost cause & I shan’t bother replying.
Let’s say you write a driver for OpenBSD’s kernel. It’s a good driver. And, obviously, BSD licensed. Now, the BSD license usage means you know people might incorporate your code in their proprietary app – never mind though, your license allows it, and a “fully free” license allows for such behaviour. However, rather than being included in some proprietary app, it’s ported to Linux and relicensed as GPL. Again, the license permits this – but now you have people making enhancements and improvements to your code, and sharing them amongst themselves, but not with you. Rather than your project simply being “used” in some dead-end capacity, it’s been forked completely – and intentionally in such a way that you don’t get any of the additions to that fork back. Developers end up going to the fork, not to the original, and unless they consciously dual-license their changes, said changes are lost to the original. You don’t “lose” when your code goes into a proprietary app, as it’s not as if companies which do that make any changes you’d want to take back.
GPL is a restrictive license compared to BSD, in that it’s “forced freedom” rather than “enabled freedom” – and most people would call it unsavoury behaviour to take your code, and relicense it under their own less-Free license.
[reply]
rgz Reply:
October 9th, 2009 at 2:00 am
@directhex, wait so if I don’t agree with everything you just said (I agree with most of it) you declare me a lost cause and wont’ reply? I hope I’m wrong.
Like I said, I agree with most of what you just said there except one thing, and I quote “it’s not as if companies which do that make any changes you’d want to take back”
So did Apple not add value to KHTML with webkit? Did KDE not benefit from choosing the LGPL?
Why would a company relicense your code as proprietary if it didn’t give them a competitive advantage?
[reply]
directhex Reply:
October 9th, 2009 at 8:58 am
@rgz, I’m pretty sure I explicitly said I wanted understanding, not agreement. I don’t want people to agree, I want people to be able to understand my position. Those are not necessarily the same thing, although one may leas to the other.
You assume that it’s the use of LGPL which “forced” apple to release back Webkit – yet Darwin is decided BSD-licensed, and still sees apple giving back. It’s a question of attitude and ethics, not licenses (which is how you end up with GPL violators crying foul – they’re not interested in following ANY license, they’re simply unethical)
Taking code without giving back is a mark of low-quality code, and lack of faith in your abilities. Or, more charitably, lack of time or value. A company will relicense code as proprietary to integrate it with their own code – and the majority of changes they make will be related to that integration effort, not to feature enhancements which could or should go into your code. If they’re putting in the effort to develop your code, it serves THEIR purposes to give back, even if the license (BSD) doesn’t force them to, as it means you are able to work on new features (rather than using your time up implementing your own equivalent to their features).
Not every company wants to be pushed into relicensing their own app as GPL as a result of it. As an example, if the stock Theora decoder were GPL, then games developers wouldn’t write their own – they’d simply pay their patent fees and use MP3 or AAC or somesuch – and I don’t see propping up that kind of thing as better.
[reply]
rgz Reply:
October 9th, 2009 at 7:22 pm
@directhex, as for the first part, thanks.
It’s been a long time but my understanding is that Darwin was dropped as soon as Apple saw fit and progress in the MacOS Kernel continues behind doors or at least the last Darwin package dates back to 2006, then Apple did (at least initially) comply in the least cooperative way possible, by dropping a tar ball without any explanation of how things changed and why, I don’t see the enthusiasm to give back.
This is just a matter of opinion and we cannot agree but it seems to me you put too much faith in the cooperation of people who don’t want to cooperate.
If closed source did not exist I’m pretty sure the GPL would happily add a clause to release back changes as BSD, and you could always, use the GPL’d version, you just can’t get it into closed source products which is what the BSD license is all about, I don’t see any problems with that, only with the rhetoric that because of that the GPL doesn’t allow that is then “less free”.
Is like saying that sharia law is better than US law because it allows you to beat, starve and rape your wife, US law sure is restrictive.
But as I said this is a matter of opinion. Still the way you talk echos of back end code, do you think the GPL is still unacceptable regarding front end applications? In the case of applications like Tomboy and Gnote, don’t you think the GPL serves better since it is highly unlikely that a close source competitor would release back interface improvements?
Also Theora is an excellent example of why not every projects is served best by the GPL, but wouldn’t the LGPL be better for back end code, you can get changes back and still retain your precious option of boost closed source competitor?
directhex Reply:
October 9th, 2009 at 7:49 pm
@rgz, Gnote is an interesting example to use here. Tomboy’s core is LGPL, allowing plugins to be written using the plugin author’s license of choice. Gnote makes use of the relicensing provision in LGPL, and relicenses itself (which is a derivative work of Tomboy) as GPLv3 – forcing plugin authors to use GPLv3 (and preventing backporting of improvements of Gnote’s core to Tomboy). I just don’t see how it’s a positive thing.
rgz Reply:
October 10th, 2009 at 6:19 pm
@directhex, It’s a positive thing because it prevents a closed fork of Gnote to overcome it, by absorbing all of it features and adding more with paid developers.
I know (well, i guess) what you are going to say next, if a competitor comes and makes a better product by absorbing Gnote’s code, isn’t that good for the users? After all it’s all about the features and making the coolest software.
Wait, what was wrong with GPL’d apps again? I quote: “However, rather than being included in some proprietary app, it’s ported to Linux and relicensed as GPL. Again, the license permits this – but now you have people making enhancements and improvements to your code, and sharing them amongst themselves, but not with you. Rather than your project simply being “used” in some dead-end capacity, it’s been forked completely – and intentionally in such a way that you don’t get any of the additions to that fork back. Developers end up going to the fork, not to the original, and unless they consciously dual-license their changes, said changes are lost to the original.”
What you are describing is a classic EEE, albeit done by a GPL’d fork. So when a proprietary app does an EEE you celebrate the Embrace and the Extend and dismiss the Extinguish as either “not my problem i still have my code” or “not gonna happen because they will still give me back code” even when that helps their competition so it’s not probable.
But when a GPL’d app does an EEE you resent the Embrace, envy the Extend, and woe and audibly lament and announce the coming of the Extinguish.
That’s the double standard the “BSD is more free”-crowd have that bothers me.
Any way, I’ve come full circle, if I don’t reply further is because I’ve got nothing new to say.
Andrés G. Aragoneses Reply:
May 3rd, 2009 at 5:50 pm
@directhex, I don’t think Tomboy’s devs would do a line-by-line port from Gnote. They would just copy the feature, which means there’s no copyright issues in that.
[reply]
Gnote will never be able to keep up. Here is their thinking on new feature work:
http://live.gnome.org/Tomboy/PlaceForNewIdeas
[reply]
I strongly agree with this blog post. Considering the fact that there are people willing to change the C code in Gnome 3.0 with something really object oriented then C++ is a step backwards. From my understanding C# can be theoretically fully compiled (for better runtime performance) and can also be used with mono framework in VM (for nice smooth developement) so it will be a better choice for the Gnome 3 to use. Don’t get me wrong I am a windows user and a C/C++ programmer but i think I will get involved with Gnome if the community is willing to make a modern, future proof desktop platform. I think that there is the wrong idea inside the Linux\Gnome community that if you support the Mono framework you will only use 1 programming language and you can’t use compiled languages anymore. I think that that the Mono framework if it will get something like WPF (and I think this is only a matter of porting the clutter library and extending and porting the SVG format and cairo library) can truly be the multiplatform way for developers. This will be positive for big, expensive projects like graphical tools (i.e. GIMP, Inkscape), office suites, and other tools that linux [and other FLOSS lovers on windows and mac] currently lack while gnome [and other DEs] should invest resources in adapting internet browser engine that integrate internet services with the OS better, and average-user tools (a user friendly program for photo-editing, nice text editor with options for coders too, an VM, a compiler for the language is written in, to name just my favorites). So name it vala if you want but do Gnome in C# (version 3.0 should be enough because I don’t think someone would risk dynamically typing for this job) compiled if you can because with good GC I think it will perform better than C/C++ for DE and GUI development platform. This will truly make Gnome the desktop of the future at least in its inner guts and will convince me not only to switch but to get involved also.
[reply]
“mono… will be a better choice for the Gnome 3 to use”
I can’t think of anything worse.
Apart from Microsoft buying Miguel (Ahh no hang on…)
[reply]
Byakkun Reply:
May 3rd, 2009 at 8:42 pm
@The Open Sourcerer,
I said that C# compiled directly to machine code (i think it needs to remove the CLI requirements by writing a preprocessor, a compiler and some library in machine code and to stop using any kind of virtual machine) could be better because it is not only object oriented but it is also strongly typed, has automatic Garbage collection and other features that could make Desktop Environment and GUI developing much nicer like it is stated in this Gnome journal entry. The reference to mono is there to show that by adopting C# it will be easy, for… third party developers I guess, to target managed code development where they need portability more than fast startup (apps like those that make office suites for example that need to be done for more platforms not only gnome; i think that making many redundant apps like Inkskape/Karbon is a waste of talent and resources) and to also be able to keep the User Interface and “user experience” well integrated with Gnome’s by using bindings for Gnome in C#.
Miguel is not bought, it is only MS being grotesque in their attempt to “play nice” with the open software community that they need to write code for their products.
[reply]
[...] is a perfectly acceptable application which performs gracefully. According to this conversation, “The Fedora project further confirms this [that Gnote is fine] by including Gnote in Fedora [...]
[...] is a perfectly acceptable application which performs gracefully. According to this conversation, “The Fedora project further confirms this [that Gnote is fine] by including Gnote in Fedora [...]
“Boycott Novell Says”
LOL. who cares what the trolls running that site say..
[reply]
directhex Reply:
May 3rd, 2009 at 11:15 pm
@f, I wouldn’t want them to think I was suppressing their freedoms by deleting their pingbacks.
As for trolls, I think there’s a minimum intelligence level required for trolling.
[reply]
directhex Reply:
May 5th, 2009 at 9:00 am
Oh, and funnily enough, Jose_X stumbled onto Gnote’s little implementation secret here: http://boycottnovell.com/2009/05/03/gnote-fedora-10-and-11/#comment-62891
Gnote’s entire csharp:: namespace is a reimplementation in C++ of the required parts of the ECMA335 Base Class Library – and given Jose_X’s belief in an “API Trap”, equally risky
[reply]
[...] Hi Chaps, there’s a scary discussion going on here: http://www2.apebox.org/wor… [...]
[...] http://www2.apebox.org/wordp… [...]
wow, 4 pingbacks from the mentally challenged individuals running BN.
I wonder what they’d do if they ever found out that Canonical is hiring Mono devs for their Online Services team? ;-)
[reply]
I actually think Mono has a point and a purpose in life. Like Wine it is a great tool to reuse software developed for legacy platforms. If you happen to have a load of custom C# code that you don’t want to thow away then by all means use Mono to run it. Microsoft probably won’t pull the patents out for quite a while, probably plenty of time for current apps to become obsolete. I just don’t think Mono is a platform for building new stuff on, any more than Wine is.
[reply]
Also, the attitudes of the developers displayed in http://bugzilla.gnome.org/show_bug.cgi?id=581844 makes me favor Tomboy again. Sandy wants to make sure compatibility is maintained so users can do what they want when they want. Hub doesn’t care. He says “Copying the notes back to Tomboy is not supported either.” Sounds like he took a page out of Proprietary Software 101: how to promote lock-in.
[reply]
Me Reply:
May 13th, 2009 at 11:28 pm
@Mackenzie,
You pointed to a Tomboy bug, which the developers have had to fix.
[reply]
directhex Reply:
May 13th, 2009 at 11:38 pm
That’s moderately disingenuous. Tomboy’s bug was crashing on badly-formatted dates in note files. Gnote’s bug is that it writes bad notes in the first place. Tomboy’s author both fixed the crasher and tweaked Tomboy to support Gnote’s date format, Gnote’s author said “it’s not a bug, I don’t want people importing notes into Tomboy”
[reply]
[...] Tomboy vs Gnote Smackdown [...]
” Gnote’s author said “it’s not a bug, I don’t want people importing notes into Tomboy”
For record, you are blatantly lying. Shame on you.
[reply]
directhex Reply:
May 17th, 2009 at 11:33 am
For the record, you’re full of shit, and have demonstrated an inability to apply research.
From http://bugzilla.gnome.org/show_bug.cgi?id=581844 – “If tomboy crash then Gnote is not the one with the bug. Copying the notes back to Tomboy is not supported either. iso8601 conversion is done by glib. This bug is likely WONTFIX candidate.”
[reply]
He never said, I don’t want people to copy. He said, I don’t support it in my code because conversion is handled by glib. If you don’t the understand difference and prefer to call people shit instead, I guess that’s your choice. Your obsession with Mono makes it easier to be less neutral and actually see what the debate is all about. I feel sorry for you.
[reply]
directhex Reply:
May 18th, 2009 at 7:32 am
@neo, Your obsession with anti-Mono makes it easier to ignore dickery and gloss over what the debate is all about. I feel sorry for you.
If you’re writing an app which is a direct line-for-line rewrite of another app, and the method you’ve decided to use in your .NET BCL reimplementation is defective, then USE A DIFFERENT METHOD. It’s hardly fucking rocket science. g_time_val_to_iso8601 is crap, so don’t use it. If you actually care about your *users*, such as the fairly neutral Mackenzie who reported the bug, then you don’t use lock-in to force them to use your app, using badly written 1-way compatibility. It makes things like “The file format is the same as Tomboy’s Note Format” from http://live.gnome.org/Gnote a CLEAR attempt to deceive.
[reply]
Anders Reply:
July 20th, 2009 at 3:12 am
@directhex, Think I agree with neo and not with you here. Cool down and manner your language, please. It is hurting your mono project, if you don’t…
[reply]
It is another lie that I am anti-mono. I guess being rude instead of acknowledging your faults is what you do. Since Tomboy can deal with the different formats in the latest release, there is no deception. The Gnote developed even thanked the Tomboy developer for doing it and there is no lock-in. I wasn’t expecting anything different. Good luck.
[reply]
directhex Reply:
May 19th, 2009 at 12:33 am
@neo, Ah, ignoring the substance to attack the person. Good show, old chap. Well done. *golf clapping*
Let’s look at the timeline here:
1) Gnote implements incorrect date format
2) User reports Tomboy crashing on mangled dates as a bug against Gnote (which is responsible for said mangled dates)
3) Gnote author says he won’t fix it, and doesn’t support peopel importing their data back into Tomboy
4) Tomboy author modifies Tomboy to accept Gnote’s mangled dates, proposes collaborating on a note file format rather than second-guessing each other
5) Gnote author ignores proposal, instead complains about date formatting
How exactly is Gnote’s course in the above anything but user-hostile? Personally I’m amazed at the community-minded behaviour of Sandy in supporting Gnote’s mangled notes. I would probably have implemented a “warning, this note appears to be corrupt, attempt recovery?” dialog. But I’m a much more vindictive person it seems.
[reply]
Anders Reply:
July 20th, 2009 at 3:15 am
@directhex, “takes one to know one”.
Think about neo’s first two sentences and then your comments first two sentences when you read this. I tend to agree with neo on this…
[reply]
I’m not in a position to make statements about the quality of code for either Tomboy or Gnote, since I’m not using either, but seen from the perspective of an IT department manager, prudent bevavior for a business running Linux on the desktop would be to wait the whole controversy out, either by uninstalling libmono0 and mono-common as one commenter suggested (and using a desktop wiki like zim instead), or by selecting XFCE instead of Gnome (XFCE 4.6.1 is already functionally equivalent with Gnome, and it’s also snappier and less of a resource hog).
I’m not pro- or against Mono, I’m just saying that as long as it’s a controversial issue in the community, business will stay away from it, looking for alternatives.
[reply]
directhex Reply:
May 20th, 2009 at 4:05 pm
Which, of course, could be seen as one of the goals of certain elements of the “community”. Mono is 7 bloody years old now – how is it still causing controversy?
[reply]
There is no need to go apeshit over this. It’s good that we have diversities. Why are you so threatened by the port? Stop being such a Mono tool!
[reply]
directhex Reply:
May 27th, 2009 at 3:44 pm
The problem is that it’s grounded in douchebaggery. Taking somebody’s code, and making a 1-way change in the license, is a dick move. End of story. Telling a BSD kernel developer “oh, well you can have all the changes we made to our GPL-only fork of your code, you just need to convert to GPL” isn’t a solution in that case, nor in this identical case. It’s pure and simple douchebaggery.
Is there a “threat”? No. Gnote still implements only a small fraction of Tomboy’s functionality, including zero syncing abilities (see also http://live.gnome.org/Snowy). But it’s incredibly rude and demoralising for people to take your code and claim it for their own with less than zero desire to cooperate. Gnote’s supporters intentionally misrepresent its benefits, and engage in doublespeak – both attacking Tomboy as a “useless” app when at the same time recommending a less functional clone.
There’s also the question of the future. Where will Gnote go when (if?) it reaches feature parity with Tomboy? Continually exist as a catch-up clone, implementing Tomboy’s features as and when? When the Tomboy maintainer proposed cooperating on a note format (e.g. for interop with things like Snowy), he was rebuffed – is this productive?
[reply]
Gnote will be included in Ubuntu Karmic repositories:
http://packages.ubuntu.com/karmic/gnote
[reply]
directhex Reply:
May 31st, 2009 at 11:31 am
@EatPy, That’s not exactly news. Although it was rejected multiple times for, surprise surprise, vague copyright.
[reply]
qutoing from Gnote homepage: “The file format is the same as Tomboy’s Note Format.
But there no warranties about Tomboy being able to read them. You have been warned.”
What kind of twisted logic is that? If Tomboy can’t read gnote file format then how is that gnote’s file format is the same as Tomboy’s?
[reply]
directhex Reply:
June 12th, 2009 at 2:21 pm
@cb951303, The change happened here: http://live.gnome.org/action/info/Gnote?action=diff&rev2=24&rev1=23 (note zero comments in the wiki changelog).
What happened is that Gnote mangled Tomboy’s format, by using incompatible dates. Rather than a) accept responsibility for writing bad files, b) accepting the Tomboy developers’ offer to collaborate on a common note format, or c) removing the claim of being Tomboy-compatible, Gnote’s author instead opted to mark the issue as a WONTFIX, and made the above change to his page to imply that Tomboy is incapable of reading Tomboy files.
[reply]
[...] apologists have long been trying to tar Gnote with “copyright violation”, you can see Jo Shields waft it around a little bit here: If Debian’s FTP Master determines that Gnote is permissible for inclusion in Debian (I hear FTP [...]
@directhex : On monday, July 27, Hubert (the author of gnote) wrote a post on his blog. It’s about his reasons writing Gnote. You should check it if you’re interested.
[reply]
directhex Reply:
July 29th, 2009 at 9:55 am
@nfinity, I’ve read it. It’s worth reading. But I don’t think anything Hub has written is counter to my blog post – and even if I did, the problem with making changes is that it’d reappear at the top of RSS feeds (including Planet).
[reply]