Tamarin has very little to nothing to do with it. It has everything to do with massively cutting back on XPCOM usage within the codebase and other architectural changes which couldn't be made in a 1.x build for compatibility reasons.
In fact, Tamarin currently needs a fair amount of optimization to reach parity with Spidermonkey (in the case of untyped data anyway).
Is CDDL compatible with GPLv2? I may have mispoke in my first post, but I think the gist of what I was trying to say is still there. ZFS is behind a license which isn't compatible with the license Linux is under.
Or am I completely misunderstanding things? I'll admit I'm far from an expert on these matters...
Hasn't Linus already said he's very interested in adding it into the Linux kernel (going so far as to say that it could be a reason to consider going GPLv3 in the future if Sun releases Solaris under it), but right now it's tied up in closed source?
What, these aren't enough reasons to upgrade? Honestly, users who know vulnerabilities exist and specifically choose not to upgrade deserve what they get in my ever so humble opinion.
MoFo switching to an SQLite-driven Places bookmarks/history system
1.) Reduced final compiled codesize by a bit over 70KB (according to their own build system)
2.) Greatly improves data reliability
3.) Is either performance-neutral or in some cases actually improved performance
And you guys are complaining? If that's bloat, sign me up!
In engineering, both of the co-ops I had during college as well as the job I'm about to enter upon graduating had/have mandatory drug screenings/background checks.
as well as the patent on the x86_64 architecture which they have licensed to Intel
Correct me if I'm wrong, but I'm pretty sure x86-64 is an open standard that AMD doesn't charge royalties to use (if they even own patents on it, which again I don't think they do).
Maybe the problems you're having require moving onto a new release to be fixed properly? They're making a lot of big changes in Gecko 1.9 which would be downright impractical for Gecko 1.8.1 as they're too regression prone. It's one thing when the regressions pop up during a 1-2 development cycle for the next major release. It's another thing when they pop up in a x.0.0.y release. If they did things the way you're proposing, updates would hardly ever come out because development cycles would be horribly extended.
Wouldn't multiple blurs over the same area also make it much harder to decipher? Yes, [evil person] could apply the affect multiple times as well, but that would be assuming they knew that a) the person had done it more than once and b) how many times they'd actually done it.
Because outfits like Mozilla have only a finite amount of time and resources to work with. Also, bugs can sometimes be difficult to fix without significant changes to the underlying codebase, which can be more trouble than it's worth for a product which was released many years ago and has had significant updates released for it since.
For example, what happens if a bug is found on a frozen interface and it requires breaking that interface in order to fix it properly? Should a minor point release widely break compatibility of extensions and such for that? (In fact, many people here complain about similar situations all the time).
Besides, it's not like newer versions of Firefox cost money or something.
Because Firefox 1.0 support ended the moment 1.5 was out.
Uh, no it didn't. Firefox 1.0.x maintenance releases were stopped on April 13, 2006, the same day version 1.5.0.2 was released and nearly 4 months after version 1.5 was released.
RTFA. The immune system has to be completely wiped out at the beginning so that the modified cells have a chance to become prevalent in the body after being injected.
Tamarin has very little to nothing to do with it. It has everything to do with massively cutting back on XPCOM usage within the codebase and other architectural changes which couldn't be made in a 1.x build for compatibility reasons.
In fact, Tamarin currently needs a fair amount of optimization to reach parity with Spidermonkey (in the case of untyped data anyway).
Is CDDL compatible with GPLv2? I may have mispoke in my first post, but I think the gist of what I was trying to say is still there. ZFS is behind a license which isn't compatible with the license Linux is under. Or am I completely misunderstanding things? I'll admit I'm far from an expert on these matters...
Hasn't Linus already said he's very interested in adding it into the Linux kernel (going so far as to say that it could be a reason to consider going GPLv3 in the future if Sun releases Solaris under it), but right now it's tied up in closed source?
But, but...the Safari site says it was designed for security from the start?
http://www.apple.com/safari/ (#12 on their list)
What, these aren't enough reasons to upgrade? Honestly, users who know vulnerabilities exist and specifically choose not to upgrade deserve what they get in my ever so humble opinion.
MoFo switching to an SQLite-driven Places bookmarks/history system 1.) Reduced final compiled codesize by a bit over 70KB (according to their own build system) 2.) Greatly improves data reliability 3.) Is either performance-neutral or in some cases actually improved performance And you guys are complaining? If that's bloat, sign me up!
FWIW, I think what you're talking about is a lot of what they're planning on doing for Gecko 2.0.
In engineering, both of the co-ops I had during college as well as the job I'm about to enter upon graduating had/have mandatory drug screenings/background checks.
Most companies require at a minimum a drug screening, and maybe a physical too. I'd say both of those would mandate the use of latex gloves.
...wouldn't it have been easier to come on the intercom during the flight and tell people that a phone was interfering instead of after the flight?
Maybe the problems you're having require moving onto a new release to be fixed properly? They're making a lot of big changes in Gecko 1.9 which would be downright impractical for Gecko 1.8.1 as they're too regression prone. It's one thing when the regressions pop up during a 1-2 development cycle for the next major release. It's another thing when they pop up in a x.0.0.y release. If they did things the way you're proposing, updates would hardly ever come out because development cycles would be horribly extended.
That's an issue that's on their radar for Gecko 2.0 (Fx4) when they're doing a more massive overhaul and cleanup of Gecko.
It's in the Release Candidate stage. It won't be long :-)
Wouldn't the far bigger problem be the ensuing nuclear winter? Clearing the land is moot if there's no sunlight for plants to grow with.
Wouldn't multiple blurs over the same area also make it much harder to decipher? Yes, [evil person] could apply the affect multiple times as well, but that would be assuming they knew that a) the person had done it more than once and b) how many times they'd actually done it.
Yeah, because everybody who goes to Notre Dame is Catholic. Or everyone at BYU is Mormon.
Yes they do
Wouldn't that be carbonic acid (H2CO3)?
Because outfits like Mozilla have only a finite amount of time and resources to work with. Also, bugs can sometimes be difficult to fix without significant changes to the underlying codebase, which can be more trouble than it's worth for a product which was released many years ago and has had significant updates released for it since.
For example, what happens if a bug is found on a frozen interface and it requires breaking that interface in order to fix it properly? Should a minor point release widely break compatibility of extensions and such for that? (In fact, many people here complain about similar situations all the time).
Besides, it's not like newer versions of Firefox cost money or something.
RTFA. The immune system has to be completely wiped out at the beginning so that the modified cells have a chance to become prevalent in the body after being injected.
Here are some links to show the bugs in the Bugzilla database which were turned up by Coverity.
Open Coverity Bugs
All Coverity Bugs
Silly Dutch people and their different spelling of things ;-)