Slashdot Mirror
A Bad Month for Firefox
marty writes "Februrary is not a good month for Mozilla developers. Infoworld reports about the efforts of Polish researcher Michael Zalewski, who apparently kept finding new vulnerabilities in the popular browser on a daily basis through the month, first postponing the 2.0.0.2 update, and then finding a remotely exploitable flaw in it immediately after its release."
Well yeah that's the flipside. Some people report "bugs" which are things that cannot really be exploited in the field [e.g. unreachable exploits]. I deal with that in my OSS work as well. Though, usually I fix them anyways just for completeness. In fact, a non-trivial amount of bugs I've fixed have been of that sort [I wouldn't say a majority but definitely not just a few].
Some people like the press it gets for finding them too.
That being said, some projects react bad to bugs. GCC is an example of a group who react well to them. I've had several PR's fixed because of a simple ICE or asm dump I sent in. Whereas in the Linux camp, bug fixing is a royal right only a few can have. When I wanted to add device IDs for Intel NICs to the 2.6.18.2 [iirc] kernel I submitted a patch which added them. It was refused saying that they would be added in the next major release cycle. Even after I told them that they could trivially be added to the next point release they still refused. Oddly enough the maintainer, a Gentoo developer, added them to the gentoo brand of the kernel anyways. Go co-operation!
I dunno, for me it's a sense of responsibility. If I'm going to release software that can potentially cause problems for others, I make sure I respond to valid reports as soon as possible. I don't look at it as a negative experience because for me the alternative is to stop sharing the code alltogether.
Tom
Someday, I'll have a real sig.
There is one problem with the flaw, it's very hard to reproduce, I think I reproduced it once in a 1.8 branch build, but not afterwards.
If anyone can reproduce it consistently, and has a 1.8 debug branch build, it would be great if he could try and give a useful stacktrace in the bug.
My complaint isn't that they weren't added, it's that the maintainer refused to add them to the vanilla kernel [e.g. at kernel.org] and instead horded them for Gentoo-sources [even though I run gentoo I still feel this is wrong]. Eventually at the next major release they were added. So it's not that the device IDs were wrong or caused problems. It's that the developer didn't want to share them with the rest of the Linux crowd.
Or more to the point: the maintainer knew they would never be accepted into the stable branch kernel until, at the very least, they were tested in the dev branch first.
The maintainer doesn't have the final say. It's the stable team that decides in the end and they have only gotten more strict now that there are shorter dev cycles. Also, I didn't say that they did cause problems I said they could in theory cause problems and there is no way to know for sure until the new ids have been well tested. The change was quite probably safe but I'm astounded your whining that they would not throw improperly tested code right into the stable branch. I've seen simple device ID additions cause crashes. I've had them crash MY system. It's rare but it happens. That's why I update my servers with the stable branch and run my personal stuff on the more cutting edge devel kernels.
You should ask Jean-Luc Cooke about his experience trying to replace the horrible /dev/random device with one based on Fortuna. He got the same royal decreed from Ted T'so about "who owns the kernel" and who doesn't. In the end, Jean-Luc just gave up and withdrew the patches.
/dev/random has to be as hard to predict as possible. You claim it's horrible but there are whole papers on how to random generate numbers and even seasoned kernel devs have had patches refused patches because they weren't able to justify them properly.
The kernel is, for the most part, a horribly written, and poorly maintain piece of code. The maintainers are selfish ego-hording losers and have to really learn there is more people willing to contribute then just them.
Translation: They didn't let me do what I want to they are a bunch of jerks
There are people who dedicate themselves to teaching new people how to add patches to the kernel. The whole kernel newbies project and the kernel janitors project exist to provide developers who new to kernel programming an easy way to learn their way around and get patches accepted. There have been hundreds of patches in the past few months that were accepted from people who were previously unknown to kernel programming. So it really is open to others but only people willing to follow the rules. Those rules are there for a reason.
When it comes to software performance, it's pretty useless to compare the performance of your software to a previous version of that same software. You need to compare your performance to that of the current leader in the same market.
Maybe Firefox 2 is faster than Firefox 1.5. But compared to Opera, Konqueror and Safari, it's still quite slow and extremely bloated. Apparently it's also quite insecure, too.
KDE 4 is getting very close to being released. It's native support for Windows will bring Konqueror to a whole new audience, thus drastically changing the Windows browser landscape. Unless the Firefox developers really get their asses in gear, which apparently isn't happening, Konqueror will come along and smite Firefox.
If the beta released today is any indication of what the final KDE 4 release will be like, then Firefox had better watch out. This new version of Konqueror already has the speed. It has the stability. It has extremely low memory usage (but still higher than Opera). I don't know if Firefox will be able to compete unless a massive rewrite is undertaken. But if they do wish to remain competitive, they'd better get going.