Alright, I'll bite.
I presume you're using totem-xine, as opposed to totem-gstreamer? The first two problems are completely beyond Totem's control, and are problems with the backend library. In my experience, libxine has more such problems than GStreamer, even though it has support for a wider range of codecs.
Your fourth point about Totem's "control interface" could be valid, but some suggestions for improvement would be better, rather than just a "that's crap".
In summary: file bugs or nothing can be done about it.
That's good to hear -- statistics are good -- and I know that Carl Worth did quite a bit of work on speeding Cairo up after this was published. It would be nice to see the tests run against the latest releases of both frameworks again, and see if Cairo's narrowed the gap.
If anything's to be fixed, then statistics on what's going wrong, where, and how are needed. If they can't be produced, then there's likely nothing wrong (although I admit this doesn't apply in all cases). Profiling and hard facts describe reality.
Comparing GTK+ 2 apps to GTK+ 1 apps is typically a faux pas, as the GTK+ 2 apps have much more functionality, as they've had years more development than the old GTK+ 1 versions. I admit that GTK+ 2 itself is probably a little slower than GTK+ 1, but again, that's due to extra functionality. I've looked around for some figures, and haven't been able to find any actual figures, but I've got an interview with Owen Taylor shortly after the release of GTK+ 2.0, and then a mailing list post about Ethereal performance a month or so later. The second one gives a more rosy view, and since optimisations and improvements have been made since (see Federico's 2005 presentation on optimising GNOME for an example), I'd be fairly confident that GTK+ 2 is OK.
You've been working with it for seven years, and yet everycomment of yours on GNOME and GTK+ on Slashdot in the last year has been slagging it off quite badly. It makes one wonder why you continue to code with such a "steaming pile of crap written by developers whose egos are bigger than their brains".
If by "interfaces" you mean library APIs then you're dead wrong. GTK+, Glib and all the other core libraries of GNOME have had complete API and ABI stability since the first 2.x release. We're more than happy to fix problems if they're pointed out to us, or if we find them ourselves. I personally get quite annoyed, however, when someone waves their hands in the air and says "it's common knowledge that Gnome has problems", without a scrap of proof or supporting data.
You don't get my point. Microsoft is going to make the Windows-using world use OOXML, and I don't think there's anything we can do to stop them, much as we'd love to. Their market share is so great that they can quite easily push OOXML onto Office users, and as they provide a nice upgrade path from.doc format, nobody will really complain. Even if we do manage to stop them getting OOXML ratified as an ISO standard, it'll still take.doc's place as the dominant document format.
Strangely enough, I wouldn't call that a reliable citation. Statistics, profiling, and hard facts might work.
I've been a GNOME developer for about a year (working on Totem), and a user for about three. During that time, I can count the number of times the panel, Nautilus or any of the other "core" parts of GNOME have failed me on one hand, and most of that's repeated occurrence of a problem before I've fixed it.
Compromise: Make sure OOXML is sane to implement by being on the committee for it, while also pushing ODF, and continuing to not push OOXML. If our efforts to push ODF into the mainstream work, that's good. If not, at least we will have sorted the major problems with OOXML, and it'll be easier to implement (and harder for Microsoft to diverge from) in OSS.
I'll quote that to you in a few years when you find you can't open that dreadfully important OOXML file from work on your home computer. Implementing OOXML (not matter what [correct] moral outrage you have towards it) means that more people can more to open desktops more easily --- they don't have to convert all their documents, or start from scratch again. GNOME's participation in the OOXML process is merely to make sure that it's at least semi-sane for implementation in OSS, as opposed to completely opaque and mangled. If you read Jeff Waugh's comments on TFA, you'd see that GNOME is not endorsing, supporting, or pushing for adoption of OOXML; it's merely softening the blow of the (unfortunately) inevitable worldwide adoption of OOXML.
Miguel and Mono have little to do with GNOME. GNOME has a pragmatic, rather than "spineless" approach to OOXML (face it: it's going to become the new.doc format regardless of any protest or opposition from OSS, so why waste the opportunity to at least fix the most serious problems with it, and make implementation of it in OSS easier?).
I'm not even going to bother responding to your baseless claims about GNOME's functionality and design competence.
We've got energy efficiency (heat and suchlike) in houses just about covered, but what about electrical waste? It's covered briefly in the article, but I get the impression that he only plans to be conservative in what he has switched on all the time. How about something like a 12VDC power supply running throughout the entire house, so that all the billions of little 12V adaptors can be eliminated, and replaced with one large, expensive (=> efficient) one by the circuit breakers? All the little adaptors in your house consume a few watts each even if what they're powering isn't turned on, because they're so cheap.
But just using the standart gui (gnome-control-center) I should not be able to mess up my configuration - If I am then gnome-control-center has not sufficently protected me. Messing up should only be possible with an text editor or gconf which I did not use. There's not much that can go wrong with control centre. If you tell me what you did, I'll see about fixing it.
Which is what I critisise: To many separate projects. So everyone should implement their own drawing library, instead of linking to and using a standard one which is stable and efficient, and requires no duplication of effort?
If you make a mistake in any configuration file on Linux, things aren't going to work properly. That's the way of things, and there's no simple fix. It's just the same for KDE.
You might be looking for the GNOME FTP site (ftp://ftp.gnome.org/Public/gnome/sources/). It doesn't include Cairo, since that's a separate project. When compiling, the configuration script should check that you've got the minimum required versions of all dependencies, which should stop compilation from failing. GTK+ (etc.) will compile fine with any version later of a dependency than its minimum required version, so you don't really need to get a "set of fitting version together". Regardless, you should be using your distribution's package management system, since it'll likely have distribution-specific changes.
You just go to kde.org; I just go to http://www.gnome.org/start/2.18/ (linked to from gnome.org).
You sir, have no idea of what you're talking about. Quoting an error message with no context means nothing. Do you even know what GTK, Pango, Cairo and Bonobo are? What's a "common line"?
People's applications should be able to run fine without network — that's what we've got NetworkManager for. Saying that people can't work without network and then using this as an excuse to depend completely on a network connection's a bad idea. I do hope this is not what you mean.
An application written in JavaScript has to be parsed and interpreted through a VM, which takes both CPU time and memory. Native applications (typically written in C on Linux) have no need to be parsed, interpreted, or run through a VM, and so will consume less CPU time and memory. If your window manager (a pretty important part of your desktop) is in JavaScript, things are going to render more slowly, and we all know that Firefox isn't the most efficient browser out there.
(Interesting how the people who regularly spite Firefox about memory leakage don't seem to be apparent in this discussion.)
...was not to be the leanest and lightest browser out there; it was always to be a browser which had core functionality which was useful to most people, and could be extended. The features such as the microformat manager for v3 are not things one can easily and sensibly put in as an extension, as to stand any chance of being useful, they've got to be right in the core of the browser. The Firefox team does keep the overhead for new features down, and such features aren't going to get in people's way if they don't want them. Bloat would be an e-mail client, or web developer tools, as those are things that most people don't need, and wouldn't at all be useful for most people.
On the subject of memory usage, it's been said before, but it's all a matter of setting the cache sizes correctly. Every large application has memory leaks, and they can be fixed (if people stop whining and start providing proof and valgrind output); the only major problem with Firefox at the moment as regards memory is that the cache sizes aren't quite right. Let me reiterate that: the couple of hundred MB of memory it's using is a cache, not a leak.
Would you prefer crasher bugs to be fixed, or lists to be ordered nicely?
I know it's a cliche, but if you've got a problem with it *at least try to help fix it yourself*, rather than lambasting people left, right and centre.
If you look in the layout, view, xpcom and xulrunner directories, you'll find a lot of the core code. The browser directory is for the JavaScript and XUL files which make up the interface and product-specific parts of Firefox.:-)
I think this is a cop out on the memory leak issue. The simple fact of the matter is that IE 6 & 7, and Opera 9 do not suffer from memory leaks anywhere near as badly as Firefox. I can't speak to the bloat, but Opera renders very quickly, and IE7 seems pretty fast also. Fixing sloppy memory leaks should be a top priority IMO.
(Just to point out, I'm not from Mozilla, and I haven't worked on Firefox for quite a while, although I used to triage bugs.)
It could be taken as a cop-out, yes, and memory leaks are not excusable, but I think your argument is slightly off as well. IE 6 had bad memory leaks (for example, the nasty one where it wouldn't release the memory for event handlers). I don't know about IE 7 or Opera though. If fixing memory leaks was a top priority, Firefox would not be the browser it is today. Fine, it wouldn't leak memory, but since all the commonly-encountered ones (afaik) have been fixed, dev. time should be aimed at adding features where appropriate, and fixing other, more pressing bugs. Don't get me wrong – memory leaks should be fixed – but saying it should be a top priority is not the way to go about it.
Maintainability is an extremely important aspect of development. If the code is a mess, then it is not high-quality code.
I would agree with that, although I wouldn't say that (!high-quality) == low-quality. However, as far as I'm aware, the messy parts of Gecko are the ones nobody really needs to touch very often, and hence they don't have to be maintainable (although it's nice).
I'd say that cruft by definition implies low-quality code.
I would disagree there. Cruft doesn't have to be low-quality, and neither does the code that surrounds it. Cruft is just code which has lost its way.:-P
I don't follow the project closely enough to know why the quality of their code is so low
I would not agree with that at all. A not insignificant amount of the code is a mess, yes, but it's not low-quality. Being a mess never implies low quality, it just means that a decade or so of cruft has built up. There are several ongoing efforts at the moment to clean up Gecko, with the reflow branch being a major one.
The poor quality of the Firefox and Gecko codebases could be indicative of why we've seen to many quality and security problems with Firefox as of late. Firefox does suffer from pretty horrendous memory leaks, even when not using any non-default extensions.
As has been discussed on Slashdot before, I'm sure you know that any large and complex project will suffer memory leaks and security holes until they're all plugged. (That's not to say this is good, though.:-P ) If you try to abstract away all the possible causes of such annoyances so that they cannot happen, you just end up with bloated and slow code, which nobody wants. I would agree that the messier parts of Gecko's codebase may contribute more to memory leaks and security holes, but they're also (coincidentally) the bits which are the oldest, and therefore have had the most time to be hacked into shape.
This sounds useful, and it'll be interesting to see how different kernel developers respond to flaws in their kernels being published on a regular basis. I suppose some of them would prefer to just keep a private communication line with MoKB open, and some would prefer otherwise.
Why are webmasters who are currently ignoring XHTML going to be any more interested in Yet Another Dialect of HTML?
I suppose because it would be easier for them to upgrade their sites, as it was easy to upgrade from HTML 3 to HTML 4.
If W3C announced a deal with Microsoft and Adobe to phase out bad HTML "features" from their website creation tools, there might be a chance of changing something...
That would be good, but I think Microsoft's new Expressions suite is actually quite good (all valid, as far as I've heard), and Dreamweaver gets better every time I use it, although I don't think either of them are perfect.
I would argue that it means such sites have to be more careful with what they allow users to submit. I think this is probably a good thing, as it means that there would be fewer occasions where users could place XSS attack code on sites.
Slashdot Mirror
Alright, I'll bite. I presume you're using totem-xine, as opposed to totem-gstreamer? The first two problems are completely beyond Totem's control, and are problems with the backend library. In my experience, libxine has more such problems than GStreamer, even though it has support for a wider range of codecs. Your fourth point about Totem's "control interface" could be valid, but some suggestions for improvement would be better, rather than just a "that's crap". In summary: file bugs or nothing can be done about it.
That's good to hear -- statistics are good -- and I know that Carl Worth did quite a bit of work on speeding Cairo up after this was published. It would be nice to see the tests run against the latest releases of both frameworks again, and see if Cairo's narrowed the gap.
If anything's to be fixed, then statistics on what's going wrong, where, and how are needed. If they can't be produced, then there's likely nothing wrong (although I admit this doesn't apply in all cases). Profiling and hard facts describe reality.
Comparing GTK+ 2 apps to GTK+ 1 apps is typically a faux pas, as the GTK+ 2 apps have much more functionality, as they've had years more development than the old GTK+ 1 versions. I admit that GTK+ 2 itself is probably a little slower than GTK+ 1, but again, that's due to extra functionality. I've looked around for some figures, and haven't been able to find any actual figures, but I've got an interview with Owen Taylor shortly after the release of GTK+ 2.0, and then a mailing list post about Ethereal performance a month or so later. The second one gives a more rosy view, and since optimisations and improvements have been made since (see Federico's 2005 presentation on optimising GNOME for an example), I'd be fairly confident that GTK+ 2 is OK.
You've been working with it for seven years, and yet every comment of yours on GNOME and GTK+ on Slashdot in the last year has been slagging it off quite badly. It makes one wonder why you continue to code with such a "steaming pile of crap written by developers whose egos are bigger than their brains". If by "interfaces" you mean library APIs then you're dead wrong. GTK+, Glib and all the other core libraries of GNOME have had complete API and ABI stability since the first 2.x release. We're more than happy to fix problems if they're pointed out to us, or if we find them ourselves. I personally get quite annoyed, however, when someone waves their hands in the air and says "it's common knowledge that Gnome has problems", without a scrap of proof or supporting data.
You don't get my point. Microsoft is going to make the Windows-using world use OOXML, and I don't think there's anything we can do to stop them, much as we'd love to. Their market share is so great that they can quite easily push OOXML onto Office users, and as they provide a nice upgrade path from .doc format, nobody will really complain. Even if we do manage to stop them getting OOXML ratified as an ISO standard, it'll still take .doc's place as the dominant document format.
Strangely enough, I wouldn't call that a reliable citation. Statistics, profiling, and hard facts might work. I've been a GNOME developer for about a year (working on Totem), and a user for about three. During that time, I can count the number of times the panel, Nautilus or any of the other "core" parts of GNOME have failed me on one hand, and most of that's repeated occurrence of a problem before I've fixed it.
Compromise: Make sure OOXML is sane to implement by being on the committee for it, while also pushing ODF, and continuing to not push OOXML. If our efforts to push ODF into the mainstream work, that's good. If not, at least we will have sorted the major problems with OOXML, and it'll be easier to implement (and harder for Microsoft to diverge from) in OSS.
[citation needed]
I'll quote that to you in a few years when you find you can't open that dreadfully important OOXML file from work on your home computer. Implementing OOXML (not matter what [correct] moral outrage you have towards it) means that more people can more to open desktops more easily --- they don't have to convert all their documents, or start from scratch again. GNOME's participation in the OOXML process is merely to make sure that it's at least semi-sane for implementation in OSS, as opposed to completely opaque and mangled. If you read Jeff Waugh's comments on TFA, you'd see that GNOME is not endorsing, supporting, or pushing for adoption of OOXML; it's merely softening the blow of the (unfortunately) inevitable worldwide adoption of OOXML.
Miguel and Mono have little to do with GNOME. GNOME has a pragmatic, rather than "spineless" approach to OOXML (face it: it's going to become the new .doc format regardless of any protest or opposition from OSS, so why waste the opportunity to at least fix the most serious problems with it, and make implementation of it in OSS easier?).
I'm not even going to bother responding to your baseless claims about GNOME's functionality and design competence.
We've got energy efficiency (heat and suchlike) in houses just about covered, but what about electrical waste? It's covered briefly in the article, but I get the impression that he only plans to be conservative in what he has switched on all the time. How about something like a 12VDC power supply running throughout the entire house, so that all the billions of little 12V adaptors can be eliminated, and replaced with one large, expensive (=> efficient) one by the circuit breakers? All the little adaptors in your house consume a few watts each even if what they're powering isn't turned on, because they're so cheap.
Yes, but Firefox, its extensions and websites don't, and that's what Pyro's using.
If you make a mistake in any configuration file on Linux, things aren't going to work properly. That's the way of things, and there's no simple fix. It's just the same for KDE. You might be looking for the GNOME FTP site (ftp://ftp.gnome.org/Public/gnome/sources/). It doesn't include Cairo, since that's a separate project. When compiling, the configuration script should check that you've got the minimum required versions of all dependencies, which should stop compilation from failing. GTK+ (etc.) will compile fine with any version later of a dependency than its minimum required version, so you don't really need to get a "set of fitting version together". Regardless, you should be using your distribution's package management system, since it'll likely have distribution-specific changes. You just go to kde.org; I just go to http://www.gnome.org/start/2.18/ (linked to from gnome.org).
You sir, have no idea of what you're talking about. Quoting an error message with no context means nothing. Do you even know what GTK, Pango, Cairo and Bonobo are? What's a "common line"?
People's applications should be able to run fine without network — that's what we've got NetworkManager for. Saying that people can't work without network and then using this as an excuse to depend completely on a network connection's a bad idea. I do hope this is not what you mean.
An application written in JavaScript has to be parsed and interpreted through a VM, which takes both CPU time and memory. Native applications (typically written in C on Linux) have no need to be parsed, interpreted, or run through a VM, and so will consume less CPU time and memory. If your window manager (a pretty important part of your desktop) is in JavaScript, things are going to render more slowly, and we all know that Firefox isn't the most efficient browser out there. (Interesting how the people who regularly spite Firefox about memory leakage don't seem to be apparent in this discussion.)
...was not to be the leanest and lightest browser out there; it was always to be a browser which had core functionality which was useful to most people, and could be extended. The features such as the microformat manager for v3 are not things one can easily and sensibly put in as an extension, as to stand any chance of being useful, they've got to be right in the core of the browser. The Firefox team does keep the overhead for new features down, and such features aren't going to get in people's way if they don't want them. Bloat would be an e-mail client, or web developer tools, as those are things that most people don't need, and wouldn't at all be useful for most people. On the subject of memory usage, it's been said before, but it's all a matter of setting the cache sizes correctly. Every large application has memory leaks, and they can be fixed (if people stop whining and start providing proof and valgrind output); the only major problem with Firefox at the moment as regards memory is that the cache sizes aren't quite right. Let me reiterate that: the couple of hundred MB of memory it's using is a cache, not a leak.
Would you prefer crasher bugs to be fixed, or lists to be ordered nicely? I know it's a cliche, but if you've got a problem with it *at least try to help fix it yourself*, rather than lambasting people left, right and centre.
If you look in the layout, view, xpcom and xulrunner directories, you'll find a lot of the core code. The browser directory is for the JavaScript and XUL files which make up the interface and product-specific parts of Firefox. :-)
(Just to point out, I'm not from Mozilla, and I haven't worked on Firefox for quite a while, although I used to triage bugs.)
It could be taken as a cop-out, yes, and memory leaks are not excusable, but I think your argument is slightly off as well. IE 6 had bad memory leaks (for example, the nasty one where it wouldn't release the memory for event handlers). I don't know about IE 7 or Opera though. If fixing memory leaks was a top priority, Firefox would not be the browser it is today. Fine, it wouldn't leak memory, but since all the commonly-encountered ones (afaik) have been fixed, dev. time should be aimed at adding features where appropriate, and fixing other, more pressing bugs. Don't get me wrong – memory leaks should be fixed – but saying it should be a top priority is not the way to go about it.
I would agree with that, although I wouldn't say that (!high-quality) == low-quality. However, as far as I'm aware, the messy parts of Gecko are the ones nobody really needs to touch very often, and hence they don't have to be maintainable (although it's nice).
I would disagree there. Cruft doesn't have to be low-quality, and neither does the code that surrounds it. Cruft is just code which has lost its way. :-P
I would not agree with that at all. A not insignificant amount of the code is a mess, yes, but it's not low-quality. Being a mess never implies low quality, it just means that a decade or so of cruft has built up. There are several ongoing efforts at the moment to clean up Gecko, with the reflow branch being a major one.
As has been discussed on Slashdot before, I'm sure you know that any large and complex project will suffer memory leaks and security holes until they're all plugged. (That's not to say this is good, though. :-P ) If you try to abstract away all the possible causes of such annoyances so that they cannot happen, you just end up with bloated and slow code, which nobody wants. I would agree that the messier parts of Gecko's codebase may contribute more to memory leaks and security holes, but they're also (coincidentally) the bits which are the oldest, and therefore have had the most time to be hacked into shape.
This sounds useful, and it'll be interesting to see how different kernel developers respond to flaws in their kernels being published on a regular basis. I suppose some of them would prefer to just keep a private communication line with MoKB open, and some would prefer otherwise.
I suppose because it would be easier for them to upgrade their sites, as it was easy to upgrade from HTML 3 to HTML 4.
That would be good, but I think Microsoft's new Expressions suite is actually quite good (all valid, as far as I've heard), and Dreamweaver gets better every time I use it, although I don't think either of them are perfect.
I would argue that it means such sites have to be more careful with what they allow users to submit. I think this is probably a good thing, as it means that there would be fewer occasions where users could place XSS attack code on sites.