Faster than the current Mozilla builds of Tamarin, which have not been optimized and in many situations are still slower than SpiderMonkey.
On the other hand, it bears noting that Tamarin isn't going to make it into shipping code until Mozilla 2.0--presumably that will be Firefox 4, but it's still so far off that I believe that determination hasn't even been made yet. Whereas on past experience I would expect SquirrelFish to be in a shipping Safari build much sooner.
You can enable extensions not explicitly marked as compatible with Firefox 3 beta by going to about:config and adding an entry for extensions.checkCompatibility : false. I'm running the same extensions and usage pattern as with Firefox 2 and performance is MUCH improved, especially AJAX performance on Gmail and shutdown/session recover speed. Of course, it has only been one day since my last FF restart. FWIW, I'm running about 8 extensions and have about 50 tabs open across 5 windows; currently on my 2GB machine Task Manager shows Firefox 3 using 235MB, where in the past Firefox 2 would easily consume ~450MB or even 600MB+ under similar workload. (Of course in the past I only checked Task Manager once FF's performance became noticeably slow, so this is not necessarily a good comparison.)
Another point regarding your IE7 and Opera9 tests: as far as I know, all modern browsers choose to allocate more or less memory depending on how much memory the OS reports as available (certainly Firefox does), so users on different boxes can show very different results.
Blind tasting is a completely standard part of wine criticism and appreciation. For instance, Wine Spectator (the highest circulation wine magazine) requires that all official ratings be tasted under blind conditions, and while that is not a strict requirement for ratings in the Wine Advocate (Robert Parker's newsletter), it is the standard practice for most of the critics there including Parker. Furthermore, many if not most organized tastings for serious amateur wine enthusiasts are blind.
To be fair, it should be noted that what the wine world considers "blind" tasting does not meet the standards of double-blind scientific trials, nor even, typically, single-blind. Wine critics will typically know the region and vintage they are tasting, and possibly even which specific 30-50 wines they are going to taste. Participants at organized amateur tastings almost always know the identities of the 15-30 wines they will taste--which again will tend to be from the same region and time period--although sometimes not the identity of the "ringer" (a wine from a totally different region) which is typically thrown in keep everyone on their toes. Of course all of these not-quite-blind conditions are much more rigorous than the simple A-B-A setup which audio equipment reviewers refuse to use.
All of this is true even though there are legitimate reasons to prefer "sighted" tastings. Unlike stereo equipment which is a purely technical product with a well-defined goal (i.e. perfect reproduction of recorded sound), wine is to at least some extent a cultural product, with regional issues of tradition and food pairings complicating the notion of a single objective ideal. And even someone who thinks tradition and regionalism are bunk in today's global wine market should be able to appreciate that an Australian Shiraz which tastes like a typical Australian Shiraz should be rated higher than a Bordeaux which tastes like an Aussie Shiraz if only from the standpoint of predictability.
Wine is also a dynamic product which evolves as it ages. Although all but a very few wines only get rated on release, many styles of wine will not be at their best until years or even decades later. Knowledge not only of a wine's region but sometimes of its producer and his track record can provide helpful context when assessing whether a young wine has a promising future ahead of it. In some ways, tasting a wine blind is less like assessing stereo equipment blind (which should always be standard practice) and more like reviewing a new album "blind", which is never done for obvious reasons.
Notwithstanding all of this, the standard practice--at least in American wine criticism--is to rate through blind tastings. Look, there is certainly a fair amount of romanticism, pseudo-science and elitism in the wine world. But it is on a completely different planet from the cultish freakshow that is audiophilia.
No. Any linking, compile-time or run-time, falls under the GPL. This is why library code is more appropriately licensed under the LGPL, which does allow linking with non-(L)GPL code.
One last note, GPL code is not literally viral in the sense that if you link your code to it and redistribute your code is automagically GPLed. Rather, you are merely committing copyright infringement and need to reach an accommodation with the copyright holder. *One* way to do so would be to GPL your code, but another would be to withdraw it and replace the GPL portion with your own code or other code whose license you comply with.
Well there were about 2.5 million shares short, so even if they all covered that wouldn't even account for half of today's volume. Plus there's no good reason for a short to cover now--yes, there is value in taking your gains up front rather than waiting for it to drop those last 40 cents, but anyone short this stock has to recognize that SCOX is very likely only a few months from bankruptcy which would mean the stock goes to zero and they don't have to buy back their shares at all.
The more likely explanation for most of today's volume is day traders trying to make a quick buck on a suddenly liquid and highly volatile stock. Almost 6 million shares may have been traded, but my guess is that that represents a significantly lower number of shares traded back and forth multiple times.
In addition to Sharffen Berger--which as many have mentioned makes very good chocolate (which, at least so far, has not been adversely affected by their purchase by Hershey)--Guittard, who brought this complaint, also makes excellent chocolate in San Francisco.
All wine contains naturally occurring sulfites. Almost (probably 99.5%+) every wine of any quality made anywhere in the world also contains added sulfites. In large part this is to kill unwanted ambient yeasts and bacteria that could either contaminate the wine or produce unwelcome fermentation characteristics. But even in wineries kept clean enough to avoid bacterial contamination, and where ambient yeasts are used instead of cultured ones, sulfites are still almost always added to the fermented wine. That's because a buffer of sulfites is necessary to react with free oxygen in the barrel/tank and in the bottle, plus whatever oxygen slowly seeps in through the cork (or other closure; stevlin screwcaps are less oxygen permeable but not completely impermeable). Otherwise the wine gets oxidized. And, in general, the naturally occurring sulfites are not enough, especially if the wine is going to be aged for any length of time. Indeed, the irony of people who ignorantly complain about the "added sulfites" indicating cheap or industrial wine is that the wines with the highest levels of added sulfites are generally the greatest wines in the world, as they are the ones intended to be aged potentially for decades.
Now, there are a very few wines that do not contain added sulfites. Some are meant to be oxidized--primarily these are amontillado sherries; the only oxidized table wines I can think of are certain relatively obscure wines from the Jura region of France. Also, there is a burgeoning movement toward "natural" wines; the term is rather loosely defined, but is intended to go beyond organic and biodynamic wine-making, which refers only to the viniculture (that is, the farming), and also encompass a pure and "non-interventionist" approach to vinification as well. In general, "natural" wines are organically if not biodynamically grown, use ambient yeasts instead of cultivated yeasts (this is a big one), do not add sugar before fermentation to raise alcohol content, do not leach off excess alcohol, do not add or subtract acids, do not contain artificial additives to change color or taste, do not ferment or age with oak chips or dust or staves, do not add lab-synthesized tannins to round out their tannin profile, and do not undergo a process known as micro-oxygenation in which very tiny amounts of oxygen are pumped through wine to speed up the aging process and mimic the slow exposure to oxygen that leaks into the oak barrels in which many expensive wines are aged. (Yes, all of these techniques, and more, are very commonly used in the making of wine from all quality levels.) They typically do not add sulfites before fermentation (it would kill the natural yeasts). Some of them eschew the use of artificial temperature controls during vinification--they ferment at whatever temperature it is outside.
And some of them, very few, do not add sulfites after fermentation to preserve their wines. They are hoping that very careful vinification will protect their wine from bacterial contamination, and the proper preservative balance of alcohol, acidity and tannin will allow their wine to last a few years without oxidizing; they believe the lack of sulfites gives their wines a freshness and purity that is missing from other wines. (Note that this approach is pretty much only possible with dry red wines--dry so that ambient yeasts would not cause refermentation, and red because tannin is needed to stave off oxidation.)
As for the notion some people that the sulfites in wine give them a headache, this is poppycock. Almost always these people complain about red wines, while in fact whites have higher levels of sulfites, because they don't have tannins (which are also preservatives). Perhaps these people are reacting to something else in red wine (like tannin, or other anti-oxidants which are more prevalent in reds), or perhaps it's just psychosomatic. (Apparently studies have confirmed that Red Wine Headache really does exist in certain people, although the cause is not yet known. Additionally, some p
Yes, fish has a high ratio of Omega-3 to Omega-6 fatty acids, whereas beef has a low ratio, albeit not zero (and same with the hamburger bun). This may be responsible for a difference in nutritional effects. So might the fact that the Big Mac is full of added sugar (HFCS as it happens) and chemical flavorings to make up for the fact that the ingredients are of such low quality that they have very little taste in themselves. So might the fact that the ingredients are of such low quality that they have few of the nutrients that beef, bread, pickled cucumber, onion, lettuce, cheese, and flavored mayonnaise would ordinarily have (the same reason they have so little taste). So might the fact that the cattle was raised in a feedlot in the desert, fed a chemical-based feed of ingredients that are actively toxic to their digestive system (and which, incidentally, lowers that Omega-3 to Omega-6 ratio further), and administered a high steady dose of growth hormone and antibiotics in order to keep it alive on a diet that would otherwise kill it. So might the fact that, due to industrialized farming techniques and frequent poor handling, both the lettuce and the beef are likely to harbor dangerous bacteria like salmonella or e. coli 0157:H7, albeit only rarely in concentrations large enough to cause acute illness.
Of course this is not to say that there aren't serious issues with practices for both farmed and caught fish that may have adverse nutritional impacts as well.
There is plenty of evidence that fructose does not induce the same sort of "I''m full" response as sucrose. An increase in blood sugar from sucrose or most other sugars triggers a leptin response, which creates the perception that you are satisfied.
I don't think this is correct. Sucrose is broken into 50% fructose and 50% glucose before it hits the bloodstream. The HFCS used by industry is either 42% fructose or 55% fructose, with around 90% of the remainder being glucose. In other words, the two varieties of HFCS in use are extremely similar in chemical composition to the products of sucrose by the time it gets digested, and in fact are more different from each other than either is from sucrose. Yes, it is technically the case that sucrose needs an extra processing step to get to this state, but it is performed quite efficiently by stomach enzymes and is not generally considered to affect the body's physiological response.
From a quick check of Google Scholar I see many papers demonstrating that fructose and/or HFCS causes deleterious appetite or metabolic responses compared to pure glucose. As far as I can tell, there are no studies demonstrating any different effects compared to sucrose, and no serious hypotheses arguing that they ought to exist. (A reprint of a NY Times article on the subject can be found here (pdf).)
All of this really comes down to evolution. Fruits are a seasonal food source which is mainly available during the last part of the summer and fall. As such, fructose would be consumed by animals largely when then need to bulk up for a winter with limited food availability. Sucrose and other sugars can be found heavily in stalks and leaves of plants, and is thus available most of the year. Thus, when fructose is available, animals benefit from weight gain. By contrast, there is no such benefit from weight gain during periods where only sucrose is available, and indeed, this can be detrimental, since increased food consumption during the winter could potentially result in death of essential food plants by excessive defoliation. At least that's my theory.
This seems to reflect a common misunderstanding. High fructose corn syrup is only "high" in fructose compared to ordinary corn syrup. The most commonly used HFCS is 42% fructose, slightly lower than cane sugar; the kind used in mass-market soda is 55%, slightly higher.
I was about to make the same comment regarding alcohol and red meat. Moderate alcohol intake, in particular, appears to be tremendously beneficial; in epidemiological studies, those steadily drinking a glass or two a day show benefits over abstainers similar in magnitude to having a diet based on unsaturated fats vs. saturated (the so-called "Mediterranean diet"), or those performing regular moderate exercise vs. none.
But you make the same mistake as the grandparent poster when it comes to high fructose corn syrup. There is no research demonstrating that HFCS has any different effects on the body than plain old refined sugar. The only difference is that it's cheaper and easier to use on an industrial scale, which is why so much junk food is full of it. Most of the crap containing HFCS is sure to be bad for you, but there's no indication that replacing it with sugar would do anything but raise the price a cent or two.
A somewhat similar point can be made regarding trans-fats. We do have laboratory evidence that trans-fats both raise bad cholesterol and lower good cholesterol (saturated fats raise both), which is a good reason to be wary of them. But we have no real understanding of how that translates into actual mortality or morbidity. There is good epidemiological research indicating that people who have roughly the average American intake of trans-fats have heart attacks at roughly twice the rate of people who have none. But this doesn't take into account any of the other differences between those diets except the type of fat involved. The vast majority of the trans-fat people eat comes via fast food and pre-packaged junk food. And it's used in these products for the same reasons as HFCS: it's cheaper. Perhaps there's some other difference between a Big Mac and a sauteed piece of fish that accounts for the difference in health outcomes among those eating it than that the former is made with partially hydrogenated oils and the latter with olive oil? We just don't know yet.
And all of these effects pale in comparison to the effects of genetics and chronic smoking. The average chronic smoker takes 10 years off his life. Despite the notable increase in heart disease (and one might assume diabetes), trans-fat intake hasn't even been shown to make a statistically significant change in all-cause mortality.
I really can't wait till they levy (higher) taxes on all alcohol products (especially wine) because those products also raise the cost of health care for everyone.
Wrong. In fact, steady, moderate drinking (1 to 2 drinks a day depending on one's weight) is hugely beneficial for the prevention of hypertension, heart attack, stroke, diabetes, etc. Major studies show the positive effect is roughly equal to that of diet or of exercise.
Of course drinking and alcohol abuse do carry significant public health burdens--things like drunk driving, drunken altercations, and so forth--but all of that behavior is already illegal, and could be better targeted through any number of measures other than raising the cost of alcohol. And I'm not sure where you get your "especially wine", but as a very general rule, wine tends to be less likely the drink implicated in either these sorts of dangerous and antisocial behaviors, or in the kind of binge drinking that does lead to long-term health consequences like liver damage, etc. (For a variety of reasons: more expensive, "higher class", tends to be drunk more slowly, tends to be drunk with food, less likely to be used for the purpose of getting drunk, and so forth.)
Of course, as pretty much every state in the Union already does levy excise taxes on alcohol sales and consumption, this whole point is moot. But a much better case can be made for lowering them than raising them to punitive levels ala cigarettes.
I think they also need to tax high fat/high calorie foods for much the same reason.
Here you're on slightly better grounds, if only because current agricultural techonology, food policy and food culture provide strong financial inventives for the production and marketing of nutritionless junk. But only very slightly.
The thing is, there's nothing inherently wrong with fat or calories. Indeed, calories are literally what keeps us alive, and fat is a nutrient of primary importance. What's bad for you is eating more calories than you expend; eating saturated fats out of proportion to unsaturated and too much fat if you have a sedentary lifestyle; letting calories from low-nutrient foods crowd you out from getting balanced nutrition; and so on. There are only a very few food components--trans-fats, for instance--that are actively bad for you. Beyond that, there are no bad food items, only bad diets--and even then, only in combination with one's metabolism, exercise level, stage of life, etc.
How you craft a tax on "bad for you" foods out of all that is beyond me. (If you even want to do it: as others have pointed out, smoking has direct public health and annoyance costs to society beside the indirect health care costs.)
I'm not sure about the HTTP protocol (which I assume is what you meant), the Windows networking stack or the web server, but the Mozilla networking code will not allow more than 8 concurrent pipelined requests, no matter how high you set the preference. So yes, setting it to 30 or 3000 is identical to setting it to 8.
So far this announcement only mentions security issues, but I don't see how those would justify a new version number, despite the obvious marketing bump of having one. A rearchitecture of ActiveX and the security zones would more properly be termed XP SP3, and a couple of anti-phishing UI changes do not a new major version make.
Instead what this says to me is that MS has changed course and will be delivering XAML on Windows XP. That's not surprising--it's easily more of a no-brainer for their strategy than porting Avalon and Indigo, which they've already announced--but it is potentially very, very dangerous for the future of the open web.
Remember, MS has very different strategic goals for a web browser than we do. They see the browser as a way to lock developers into Visual Studio and users into Windows. That is the entire purpose of their browser strategy: to spread incompatible proprietary technologies. That they are willing to give up on Longhorn upgrade sales in order to increase uptake of XAML shows that they are worried, but that doesn't mean they won't succeed. Will be interesting if they are willing to sacrifice upgrades from Win2000 users as well. My bet is yes.
For many people, current releases of Firefox and Mozilla Suite will randomly render Slashdot with incorrect widths for the left column--sometimes the middle column will be too far to the left and overlap text in the left column, other times it will be way over to the right and you have to scroll horizontally to read it.
The issue is due to a race condition in the reflow code in pre-1.8 versions of Gecko. Whether it gets triggered on a given load of Slashdot depends on the timing of interactions between the incoming TCP packets containing the page HTML, the browser cache if parts of the page are cached, and the rendering engine. Some people never see it, due presumably to the vagaries of their Internet connection. Those who do (like me) can very quickly fix it by forcing a page reflow--the easiest way to do this is to quickly decrease (and then increase) the font size.
The proximate cause is malformed HTML generated by Slashcode, but obviously a race condition that leads to inconsistent rendering of the same page is a bug, and has been fixed in the Mozilla trunk. Apps based on versions of Gecko from the 1.8 codebase onward (Mozilla Suite 1.8, Firefox 1.1, Thunderbird 1.1, etc.) will have the fix applied.
Congratulations! Now you can understand half the comments every time a Mozilla/Firefox story gets posted on Slashdot.
Obviously MS is not ready to drop support for IE5/Win, which is still an unfortunately major browser--certainly well above Firefox in marketshare if you lump 5.0 and 5.5 together. Rather they have dropped support for IE5/Mac, which is still somewhat surprising considering it is the "current" version of their Mac browser (unless you count an upgrade for MSN customers only).
Incidentally, the site renders fine in Safari except for a somewhat ridiculous looking problem where the search button runs smack into Safari's OS X native widgets.
Sorry, but your taste in benchmarks isn't worth much to anyone but you.
TPC-C is the gold standard for discussion of high-level database workloads. When academics, system designers, EEs and Internet hangers-on discuss large enterprise servers, they talk TPC-C. Sorry, but brand new TPC-H results don't get breathlessly posted to the RWT forums or comp.arch.
Of course that does not mean that TPC-H is not more relevant to some workloads or that those whose needs match those workloads should not pay attention to TPC-H. It does mean, however, that TPC-C is considered by system designers to be a more interesting workload and that TPC-C gets considerably more attention from all vendors except (apparently) Sun.
I don't know of many machines in the 15k's class.
Um...HP Superdome, IBM p595 (and i595). SGI Altix 3700 is not (currently) positioned at the enterprise space due to marketing and software stack constraints, but the machines themselves much more than qualify. Of course, in their top-end configurations these machines aren't really in the 15k's class--they are far above it in both performance and accompanying price.
On the SPARC ISA, Fujitsu's Primepower 2500 is at least the equal of a 15k. If we don't mind including obsolete machines, the Alphaserver GS1280 would easily outperform a 15k, and a top-end PA-RISC Superdome could match it.
On a purely hardware level, the closest match to a 15k is probably an old SGI Origin (although these scaled higher when fully tricked-out)--a giant flock of in-order chickens. (Incidentally, the top-end Sun kit is now the E25k, which can accomodate a 72 socket/144 core USIV configuration, but the above still applies.)
The fact that at similar processor counts (and even at similar socket counts for the USIV-based kit) they are outclassed on the order of 3:1 on industry standard benchmarks by Itanium 2 and Power5. Of course it's hard to make these sorts of comparisons across a wide range of enterprise workloads, because Sun is too embarrassed to submit scores to e.g. TPC-C, the most important enterprise benchmark there is.
Obviously a 15k isn't pathetically underpowered by any objective standard; only in comparison to other machines in its class and price range.
The license being used by Solaris 10 is just the Mozilla license modified to provide additional protection against patents.
Technically this is false; the differences between CDDL and MPL are either cosmetic-only (Sun's position), or could interact with Sun's patent swap with Microsoft in subtle ways that give third-party developers fewer rights than Sun (recent concerns at Groklaw, which have not been resolved). In any case, MPL contains at least as much protection against patents as CDDL.
More important, though, mozilla.org code is tri-licensed under the GPL and LGPL as well as the MPL. You can obtain it under whichever license you wish. That means the code can be combined with GPL code (obtain under GPL); combined with e.g. CDDL'd Solaris code under the MPL-compatible CDDL (obtain under MPL); or contained in a library linked to by code of any license, including proprietary licenses (obtain under LGPL).
Solaris 10, of course, is licensed under CDDL only.
In other words Solaris 10 is just as Open Source as FireFox.
Solaris 10 is just as Open Source as Firefox, because "Open Source" is a well-defined term that they both meet. However, Solaris 10 is nowhere near as useful to the F/OSS community as Firefox code or any mozilla.org code.
More to the point, the Mozilla Foundation's licensing policy is to make their code as open and available to reuse as possible without allowing it to be completely co-opted ala a BSD-style license. Sun's policy is just the opposite. On paper the MPL/CDDL is a great license, probably better than GPL in this patent-encumbered age. But in reality almost the entire ecosystem of quality F/OSS operating system code--both kernel and utilities--is GPL'd. Sun's choice of license was clearly motivated by a desire to remain license-incompatible with that huge body of code, seemingly in a quixotic attempt to draw resources from Linux and split the Open Source community in two.
Having said that, it was still a very positive thing to have open sourced Solaris, and an Open but GPL-incompatible license is about the best anyone could have expected from Sun given their precarious competitive position. (Lock-in and familiarity with Solaris are the only reasons anyone continues to buy their pathetically underpowered hardware.)
But the difference between Sun and Mozilla is anything but trivial.
Sure, but the point is this is far from an isolated incident--indeed, pretty much all of the feature stories on the development of Firefox in the mainstream media have focused on the Blake Ross angle. E.g. there was an article and accompanying interview in the Times of London; and he's got the cover of the upcoming Wired magazine (although apparently the article and interior photos feature Ben Goodger as well). And there have been a couple other examples as well.
And to be fair it *is* an interesting story. It's just kind of funny because I don't think anyone involved with Mozilla really expected this line of coverage, or thinks it gives much insight into Firefox as a whole.
Blake's involvement is definitely being overhyped for the "college kid takes on Bill Gates" aspect, as both he and everyone else at the Mozilla Foundation will be quick to acknowledge. He did play a central role in getting the Firefox project started--but along with Dave Hyatt, who is now a developer for Apple's Safari browser. (Surprised we don't hear as much about Hyatt's role in the story?)
I think if there's one person who really deserves credit as "the guy behind Firefox," it's Ben Goodger, UI nazi and lead developer from 0.7 onwards. After all, as Firefox is mostly just a UI gloss on the underlying Mozilla code, it's Ben's rigorous adherence to principles of good, clean, simple UI that has made Firefox the breakaway success that the Suite never was.
But really that just emphasizes how much Firefox depends on the entire Mozilla project, with its thousands of sometime developers and probably a few dozens of real core superstars. That's the real story here, but so far the media has chosen not to cover it.
Apps based on the Mozilla codebase (Firefox, Mozilla Suite, Thunderbird, Camino, Sunbird, NVu, etc.) are developed on a trunk-and-branch system. The "trunk" development stream is where all the heavy lifting and generic improvements to the core components get done. The core components all those apps share include things like Gecko (XHTML/CSS layout engine and DOM), Necko (networking), SpiderMonkey (Javascript engine), XUL (cross-platform graphical toolkit; not used by Camino), and many more. In addition to these shared components, there is of course app-specific code for each application, implementing that app's interface, features, bug-fixes, etc.
A few months before an app hits a milestone release intended for end-users (i.e. Mozilla Suite 1.8, Firefox 1.1, etc.), a "branch" will be cut from a snapshot of the trunk. Checkins to the branch are meant to get the app to release quality: bug-fixes, interface tweaks, cutting features that aren't quite ready for prime time, rushing in low-risk features with a big impact in end-user usability. (Meantime, checkins to the trunk continue as normal.) The branch will progress through some number of alpha releases, beta releases, and release candidates before culminating in a final point release. Then the branch gets shut down, the applicable bug fixes are merged back into the trunk code, and the process starts again.
Now, at any point you can checkout the entire trunk from CVS and, depending on a couple parameters in your build script, compile it into Firefox, or Mozilla Suite, or Thunderbird or whatever. (Or you can download a nightly trunk build of Firefox or the Suite.) But what you get is by definition in pre-alpha state; you might end up with half-baked features, features not matched up with the UI, and so forth. So trunk builds are mostly just useful for developers (whereas branch builds are useful for both developers and people doing QA).
Lately there's been more divergence between Firefox/Thunderbird and Mozilla Suite than normal because Firefox 0.9-1.0 and Thunderbird 0.7-1.0 were all cut from the same long-lived (7 months or so) branch, which was intended to allow them to get to 1.0 quality. Indeed the major work for the 1.1 releases is just to re-sync them with the trunk. But the plan is for shorter branches from here on out, at least until the 2.0 push.
So to answer your questions: there is a common core project, and most of the core components are shared, although they become out of sync on the branches. It's an open source project, so bugs and features get attention depending on what developers (or their employers) are interested in. It is indeed a point of contention that Firefox and Thunderbird increasingly tend to get more development resources than the Suite, but they both get to take advantage of improvements to the core components. And in that sense, at least, the codebases are not fragmenting; instead they're becoming more similar after a relatively long-lived divergence.
Slashdot Mirror
Faster than the current Mozilla builds of Tamarin, which have not been optimized and in many situations are still slower than SpiderMonkey.
On the other hand, it bears noting that Tamarin isn't going to make it into shipping code until Mozilla 2.0--presumably that will be Firefox 4, but it's still so far off that I believe that determination hasn't even been made yet. Whereas on past experience I would expect SquirrelFish to be in a shipping Safari build much sooner.
You can enable extensions not explicitly marked as compatible with Firefox 3 beta by going to about:config and adding an entry for extensions.checkCompatibility : false. I'm running the same extensions and usage pattern as with Firefox 2 and performance is MUCH improved, especially AJAX performance on Gmail and shutdown/session recover speed. Of course, it has only been one day since my last FF restart. FWIW, I'm running about 8 extensions and have about 50 tabs open across 5 windows; currently on my 2GB machine Task Manager shows Firefox 3 using 235MB, where in the past Firefox 2 would easily consume ~450MB or even 600MB+ under similar workload. (Of course in the past I only checked Task Manager once FF's performance became noticeably slow, so this is not necessarily a good comparison.)
Another point regarding your IE7 and Opera9 tests: as far as I know, all modern browsers choose to allocate more or less memory depending on how much memory the OS reports as available (certainly Firefox does), so users on different boxes can show very different results.
Blind tasting is a completely standard part of wine criticism and appreciation. For instance, Wine Spectator (the highest circulation wine magazine) requires that all official ratings be tasted under blind conditions, and while that is not a strict requirement for ratings in the Wine Advocate (Robert Parker's newsletter), it is the standard practice for most of the critics there including Parker. Furthermore, many if not most organized tastings for serious amateur wine enthusiasts are blind.
To be fair, it should be noted that what the wine world considers "blind" tasting does not meet the standards of double-blind scientific trials, nor even, typically, single-blind. Wine critics will typically know the region and vintage they are tasting, and possibly even which specific 30-50 wines they are going to taste. Participants at organized amateur tastings almost always know the identities of the 15-30 wines they will taste--which again will tend to be from the same region and time period--although sometimes not the identity of the "ringer" (a wine from a totally different region) which is typically thrown in keep everyone on their toes. Of course all of these not-quite-blind conditions are much more rigorous than the simple A-B-A setup which audio equipment reviewers refuse to use.
All of this is true even though there are legitimate reasons to prefer "sighted" tastings. Unlike stereo equipment which is a purely technical product with a well-defined goal (i.e. perfect reproduction of recorded sound), wine is to at least some extent a cultural product, with regional issues of tradition and food pairings complicating the notion of a single objective ideal. And even someone who thinks tradition and regionalism are bunk in today's global wine market should be able to appreciate that an Australian Shiraz which tastes like a typical Australian Shiraz should be rated higher than a Bordeaux which tastes like an Aussie Shiraz if only from the standpoint of predictability.
Wine is also a dynamic product which evolves as it ages. Although all but a very few wines only get rated on release, many styles of wine will not be at their best until years or even decades later. Knowledge not only of a wine's region but sometimes of its producer and his track record can provide helpful context when assessing whether a young wine has a promising future ahead of it. In some ways, tasting a wine blind is less like assessing stereo equipment blind (which should always be standard practice) and more like reviewing a new album "blind", which is never done for obvious reasons.
Notwithstanding all of this, the standard practice--at least in American wine criticism--is to rate through blind tastings. Look, there is certainly a fair amount of romanticism, pseudo-science and elitism in the wine world. But it is on a completely different planet from the cultish freakshow that is audiophilia.
No. Any linking, compile-time or run-time, falls under the GPL. This is why library code is more appropriately licensed under the LGPL, which does allow linking with non-(L)GPL code.
One last note, GPL code is not literally viral in the sense that if you link your code to it and redistribute your code is automagically GPLed. Rather, you are merely committing copyright infringement and need to reach an accommodation with the copyright holder. *One* way to do so would be to GPL your code, but another would be to withdraw it and replace the GPL portion with your own code or other code whose license you comply with.
Well there were about 2.5 million shares short, so even if they all covered that wouldn't even account for half of today's volume. Plus there's no good reason for a short to cover now--yes, there is value in taking your gains up front rather than waiting for it to drop those last 40 cents, but anyone short this stock has to recognize that SCOX is very likely only a few months from bankruptcy which would mean the stock goes to zero and they don't have to buy back their shares at all.
The more likely explanation for most of today's volume is day traders trying to make a quick buck on a suddenly liquid and highly volatile stock. Almost 6 million shares may have been traded, but my guess is that that represents a significantly lower number of shares traded back and forth multiple times.
In addition to Sharffen Berger--which as many have mentioned makes very good chocolate (which, at least so far, has not been adversely affected by their purchase by Hershey)--Guittard, who brought this complaint, also makes excellent chocolate in San Francisco.
All wine contains naturally occurring sulfites. Almost (probably 99.5%+) every wine of any quality made anywhere in the world also contains added sulfites. In large part this is to kill unwanted ambient yeasts and bacteria that could either contaminate the wine or produce unwelcome fermentation characteristics. But even in wineries kept clean enough to avoid bacterial contamination, and where ambient yeasts are used instead of cultured ones, sulfites are still almost always added to the fermented wine. That's because a buffer of sulfites is necessary to react with free oxygen in the barrel/tank and in the bottle, plus whatever oxygen slowly seeps in through the cork (or other closure; stevlin screwcaps are less oxygen permeable but not completely impermeable). Otherwise the wine gets oxidized. And, in general, the naturally occurring sulfites are not enough, especially if the wine is going to be aged for any length of time. Indeed, the irony of people who ignorantly complain about the "added sulfites" indicating cheap or industrial wine is that the wines with the highest levels of added sulfites are generally the greatest wines in the world, as they are the ones intended to be aged potentially for decades.
Now, there are a very few wines that do not contain added sulfites. Some are meant to be oxidized--primarily these are amontillado sherries; the only oxidized table wines I can think of are certain relatively obscure wines from the Jura region of France. Also, there is a burgeoning movement toward "natural" wines; the term is rather loosely defined, but is intended to go beyond organic and biodynamic wine-making, which refers only to the viniculture (that is, the farming), and also encompass a pure and "non-interventionist" approach to vinification as well. In general, "natural" wines are organically if not biodynamically grown, use ambient yeasts instead of cultivated yeasts (this is a big one), do not add sugar before fermentation to raise alcohol content, do not leach off excess alcohol, do not add or subtract acids, do not contain artificial additives to change color or taste, do not ferment or age with oak chips or dust or staves, do not add lab-synthesized tannins to round out their tannin profile, and do not undergo a process known as micro-oxygenation in which very tiny amounts of oxygen are pumped through wine to speed up the aging process and mimic the slow exposure to oxygen that leaks into the oak barrels in which many expensive wines are aged. (Yes, all of these techniques, and more, are very commonly used in the making of wine from all quality levels.) They typically do not add sulfites before fermentation (it would kill the natural yeasts). Some of them eschew the use of artificial temperature controls during vinification--they ferment at whatever temperature it is outside.
And some of them, very few, do not add sulfites after fermentation to preserve their wines. They are hoping that very careful vinification will protect their wine from bacterial contamination, and the proper preservative balance of alcohol, acidity and tannin will allow their wine to last a few years without oxidizing; they believe the lack of sulfites gives their wines a freshness and purity that is missing from other wines. (Note that this approach is pretty much only possible with dry red wines--dry so that ambient yeasts would not cause refermentation, and red because tannin is needed to stave off oxidation.)
As for the notion some people that the sulfites in wine give them a headache, this is poppycock. Almost always these people complain about red wines, while in fact whites have higher levels of sulfites, because they don't have tannins (which are also preservatives). Perhaps these people are reacting to something else in red wine (like tannin, or other anti-oxidants which are more prevalent in reds), or perhaps it's just psychosomatic. (Apparently studies have confirmed that Red Wine Headache really does exist in certain people, although the cause is not yet known. Additionally, some p
Yes, fish has a high ratio of Omega-3 to Omega-6 fatty acids, whereas beef has a low ratio, albeit not zero (and same with the hamburger bun). This may be responsible for a difference in nutritional effects. So might the fact that the Big Mac is full of added sugar (HFCS as it happens) and chemical flavorings to make up for the fact that the ingredients are of such low quality that they have very little taste in themselves. So might the fact that the ingredients are of such low quality that they have few of the nutrients that beef, bread, pickled cucumber, onion, lettuce, cheese, and flavored mayonnaise would ordinarily have (the same reason they have so little taste). So might the fact that the cattle was raised in a feedlot in the desert, fed a chemical-based feed of ingredients that are actively toxic to their digestive system (and which, incidentally, lowers that Omega-3 to Omega-6 ratio further), and administered a high steady dose of growth hormone and antibiotics in order to keep it alive on a diet that would otherwise kill it. So might the fact that, due to industrialized farming techniques and frequent poor handling, both the lettuce and the beef are likely to harbor dangerous bacteria like salmonella or e. coli 0157:H7, albeit only rarely in concentrations large enough to cause acute illness.
Of course this is not to say that there aren't serious issues with practices for both farmed and caught fish that may have adverse nutritional impacts as well.
There is plenty of evidence that fructose does not induce the same sort of "I''m full" response as sucrose. An increase in blood sugar from sucrose or most other sugars triggers a leptin response, which creates the perception that you are satisfied.
I don't think this is correct. Sucrose is broken into 50% fructose and 50% glucose before it hits the bloodstream. The HFCS used by industry is either 42% fructose or 55% fructose, with around 90% of the remainder being glucose. In other words, the two varieties of HFCS in use are extremely similar in chemical composition to the products of sucrose by the time it gets digested, and in fact are more different from each other than either is from sucrose. Yes, it is technically the case that sucrose needs an extra processing step to get to this state, but it is performed quite efficiently by stomach enzymes and is not generally considered to affect the body's physiological response.
From a quick check of Google Scholar I see many papers demonstrating that fructose and/or HFCS causes deleterious appetite or metabolic responses compared to pure glucose. As far as I can tell, there are no studies demonstrating any different effects compared to sucrose, and no serious hypotheses arguing that they ought to exist. (A reprint of a NY Times article on the subject can be found here (pdf).)
All of this really comes down to evolution. Fruits are a seasonal food source which is mainly available during the last part of the summer and fall. As such, fructose would be consumed by animals largely when then need to bulk up for a winter with limited food availability. Sucrose and other sugars can be found heavily in stalks and leaves of plants, and is thus available most of the year. Thus, when fructose is available, animals benefit from weight gain. By contrast, there is no such benefit from weight gain during periods where only sucrose is available, and indeed, this can be detrimental, since increased food consumption during the winter could potentially result in death of essential food plants by excessive defoliation. At least that's my theory.
This seems to reflect a common misunderstanding. High fructose corn syrup is only "high" in fructose compared to ordinary corn syrup. The most commonly used HFCS is 42% fructose, slightly lower than cane sugar; the kind used in mass-market soda is 55%, slightly higher.
I was about to make the same comment regarding alcohol and red meat. Moderate alcohol intake, in particular, appears to be tremendously beneficial; in epidemiological studies, those steadily drinking a glass or two a day show benefits over abstainers similar in magnitude to having a diet based on unsaturated fats vs. saturated (the so-called "Mediterranean diet"), or those performing regular moderate exercise vs. none.
But you make the same mistake as the grandparent poster when it comes to high fructose corn syrup. There is no research demonstrating that HFCS has any different effects on the body than plain old refined sugar. The only difference is that it's cheaper and easier to use on an industrial scale, which is why so much junk food is full of it. Most of the crap containing HFCS is sure to be bad for you, but there's no indication that replacing it with sugar would do anything but raise the price a cent or two.
A somewhat similar point can be made regarding trans-fats. We do have laboratory evidence that trans-fats both raise bad cholesterol and lower good cholesterol (saturated fats raise both), which is a good reason to be wary of them. But we have no real understanding of how that translates into actual mortality or morbidity. There is good epidemiological research indicating that people who have roughly the average American intake of trans-fats have heart attacks at roughly twice the rate of people who have none. But this doesn't take into account any of the other differences between those diets except the type of fat involved. The vast majority of the trans-fat people eat comes via fast food and pre-packaged junk food. And it's used in these products for the same reasons as HFCS: it's cheaper. Perhaps there's some other difference between a Big Mac and a sauteed piece of fish that accounts for the difference in health outcomes among those eating it than that the former is made with partially hydrogenated oils and the latter with olive oil? We just don't know yet.
And all of these effects pale in comparison to the effects of genetics and chronic smoking. The average chronic smoker takes 10 years off his life. Despite the notable increase in heart disease (and one might assume diabetes), trans-fat intake hasn't even been shown to make a statistically significant change in all-cause mortality.
The middle mouse button already lets you close inactive tabs.
Phones and TVs only have no need to support the existing Internet if their users don't want to see anything but vendor-controlled proprietary content.
I really can't wait till they levy (higher) taxes on all alcohol products (especially wine) because those products also raise the cost of health care for everyone.
Wrong. In fact, steady, moderate drinking (1 to 2 drinks a day depending on one's weight) is hugely beneficial for the prevention of hypertension, heart attack, stroke, diabetes, etc. Major studies show the positive effect is roughly equal to that of diet or of exercise.
Of course drinking and alcohol abuse do carry significant public health burdens--things like drunk driving, drunken altercations, and so forth--but all of that behavior is already illegal, and could be better targeted through any number of measures other than raising the cost of alcohol. And I'm not sure where you get your "especially wine", but as a very general rule, wine tends to be less likely the drink implicated in either these sorts of dangerous and antisocial behaviors, or in the kind of binge drinking that does lead to long-term health consequences like liver damage, etc. (For a variety of reasons: more expensive, "higher class", tends to be drunk more slowly, tends to be drunk with food, less likely to be used for the purpose of getting drunk, and so forth.)
Of course, as pretty much every state in the Union already does levy excise taxes on alcohol sales and consumption, this whole point is moot. But a much better case can be made for lowering them than raising them to punitive levels ala cigarettes.
I think they also need to tax high fat/high calorie foods for much the same reason.
Here you're on slightly better grounds, if only because current agricultural techonology, food policy and food culture provide strong financial inventives for the production and marketing of nutritionless junk. But only very slightly.
The thing is, there's nothing inherently wrong with fat or calories. Indeed, calories are literally what keeps us alive, and fat is a nutrient of primary importance. What's bad for you is eating more calories than you expend; eating saturated fats out of proportion to unsaturated and too much fat if you have a sedentary lifestyle; letting calories from low-nutrient foods crowd you out from getting balanced nutrition; and so on. There are only a very few food components--trans-fats, for instance--that are actively bad for you. Beyond that, there are no bad food items, only bad diets--and even then, only in combination with one's metabolism, exercise level, stage of life, etc.
How you craft a tax on "bad for you" foods out of all that is beyond me. (If you even want to do it: as others have pointed out, smoking has direct public health and annoyance costs to society beside the indirect health care costs.)
Or just win+e to open Windows Explorer...
I'm not sure about the HTTP protocol (which I assume is what you meant), the Windows networking stack or the web server, but the Mozilla networking code will not allow more than 8 concurrent pipelined requests, no matter how high you set the preference. So yes, setting it to 30 or 3000 is identical to setting it to 8.
So far this announcement only mentions security issues, but I don't see how those would justify a new version number, despite the obvious marketing bump of having one. A rearchitecture of ActiveX and the security zones would more properly be termed XP SP3, and a couple of anti-phishing UI changes do not a new major version make.
Instead what this says to me is that MS has changed course and will be delivering XAML on Windows XP. That's not surprising--it's easily more of a no-brainer for their strategy than porting Avalon and Indigo, which they've already announced--but it is potentially very, very dangerous for the future of the open web.
Remember, MS has very different strategic goals for a web browser than we do. They see the browser as a way to lock developers into Visual Studio and users into Windows. That is the entire purpose of their browser strategy: to spread incompatible proprietary technologies. That they are willing to give up on Longhorn upgrade sales in order to increase uptake of XAML shows that they are worried, but that doesn't mean they won't succeed. Will be interesting if they are willing to sacrifice upgrades from Win2000 users as well. My bet is yes.
For many people, current releases of Firefox and Mozilla Suite will randomly render Slashdot with incorrect widths for the left column--sometimes the middle column will be too far to the left and overlap text in the left column, other times it will be way over to the right and you have to scroll horizontally to read it.
The issue is due to a race condition in the reflow code in pre-1.8 versions of Gecko. Whether it gets triggered on a given load of Slashdot depends on the timing of interactions between the incoming TCP packets containing the page HTML, the browser cache if parts of the page are cached, and the rendering engine. Some people never see it, due presumably to the vagaries of their Internet connection. Those who do (like me) can very quickly fix it by forcing a page reflow--the easiest way to do this is to quickly decrease (and then increase) the font size.
The proximate cause is malformed HTML generated by Slashcode, but obviously a race condition that leads to inconsistent rendering of the same page is a bug, and has been fixed in the Mozilla trunk. Apps based on versions of Gecko from the 1.8 codebase onward (Mozilla Suite 1.8, Firefox 1.1, Thunderbird 1.1, etc.) will have the fix applied.
Congratulations! Now you can understand half the comments every time a Mozilla/Firefox story gets posted on Slashdot.
Obviously MS is not ready to drop support for IE5/Win, which is still an unfortunately major browser--certainly well above Firefox in marketshare if you lump 5.0 and 5.5 together. Rather they have dropped support for IE5/Mac, which is still somewhat surprising considering it is the "current" version of their Mac browser (unless you count an upgrade for MSN customers only).
Incidentally, the site renders fine in Safari except for a somewhat ridiculous looking problem where the search button runs smack into Safari's OS X native widgets.
Sorry, but your taste in benchmarks isn't worth much to anyone but you.
TPC-C is the gold standard for discussion of high-level database workloads. When academics, system designers, EEs and Internet hangers-on discuss large enterprise servers, they talk TPC-C. Sorry, but brand new TPC-H results don't get breathlessly posted to the RWT forums or comp.arch.
Of course that does not mean that TPC-H is not more relevant to some workloads or that those whose needs match those workloads should not pay attention to TPC-H. It does mean, however, that TPC-C is considered by system designers to be a more interesting workload and that TPC-C gets considerably more attention from all vendors except (apparently) Sun.
I don't know of many machines in the 15k's class.
Um...HP Superdome, IBM p595 (and i595). SGI Altix 3700 is not (currently) positioned at the enterprise space due to marketing and software stack constraints, but the machines themselves much more than qualify. Of course, in their top-end configurations these machines aren't really in the 15k's class--they are far above it in both performance and accompanying price.
On the SPARC ISA, Fujitsu's Primepower 2500 is at least the equal of a 15k. If we don't mind including obsolete machines, the Alphaserver GS1280 would easily outperform a 15k, and a top-end PA-RISC Superdome could match it.
On a purely hardware level, the closest match to a 15k is probably an old SGI Origin (although these scaled higher when fully tricked-out)--a giant flock of in-order chickens. (Incidentally, the top-end Sun kit is now the E25k, which can accomodate a 72 socket/144 core USIV configuration, but the above still applies.)
The fact that at similar processor counts (and even at similar socket counts for the USIV-based kit) they are outclassed on the order of 3:1 on industry standard benchmarks by Itanium 2 and Power5. Of course it's hard to make these sorts of comparisons across a wide range of enterprise workloads, because Sun is too embarrassed to submit scores to e.g. TPC-C, the most important enterprise benchmark there is.
Obviously a 15k isn't pathetically underpowered by any objective standard; only in comparison to other machines in its class and price range.
More important, though, mozilla.org code is tri-licensed under the GPL and LGPL as well as the MPL. You can obtain it under whichever license you wish. That means the code can be combined with GPL code (obtain under GPL); combined with e.g. CDDL'd Solaris code under the MPL-compatible CDDL (obtain under MPL); or contained in a library linked to by code of any license, including proprietary licenses (obtain under LGPL).
Solaris 10, of course, is licensed under CDDL only.
Solaris 10 is just as Open Source as Firefox, because "Open Source" is a well-defined term that they both meet. However, Solaris 10 is nowhere near as useful to the F/OSS community as Firefox code or any mozilla.org code.
More to the point, the Mozilla Foundation's licensing policy is to make their code as open and available to reuse as possible without allowing it to be completely co-opted ala a BSD-style license. Sun's policy is just the opposite. On paper the MPL/CDDL is a great license, probably better than GPL in this patent-encumbered age. But in reality almost the entire ecosystem of quality F/OSS operating system code--both kernel and utilities--is GPL'd. Sun's choice of license was clearly motivated by a desire to remain license-incompatible with that huge body of code, seemingly in a quixotic attempt to draw resources from Linux and split the Open Source community in two.
Having said that, it was still a very positive thing to have open sourced Solaris, and an Open but GPL-incompatible license is about the best anyone could have expected from Sun given their precarious competitive position. (Lock-in and familiarity with Solaris are the only reasons anyone continues to buy their pathetically underpowered hardware.)
But the difference between Sun and Mozilla is anything but trivial.
MOD PARENT UP
Sure, but the point is this is far from an isolated incident--indeed, pretty much all of the feature stories on the development of Firefox in the mainstream media have focused on the Blake Ross angle. E.g. there was an article and accompanying interview in the Times of London; and he's got the cover of the upcoming Wired magazine (although apparently the article and interior photos feature Ben Goodger as well). And there have been a couple other examples as well.
And to be fair it *is* an interesting story. It's just kind of funny because I don't think anyone involved with Mozilla really expected this line of coverage, or thinks it gives much insight into Firefox as a whole.
Blake's involvement is definitely being overhyped for the "college kid takes on Bill Gates" aspect, as both he and everyone else at the Mozilla Foundation will be quick to acknowledge. He did play a central role in getting the Firefox project started--but along with Dave Hyatt, who is now a developer for Apple's Safari browser. (Surprised we don't hear as much about Hyatt's role in the story?)
I think if there's one person who really deserves credit as "the guy behind Firefox," it's Ben Goodger, UI nazi and lead developer from 0.7 onwards. After all, as Firefox is mostly just a UI gloss on the underlying Mozilla code, it's Ben's rigorous adherence to principles of good, clean, simple UI that has made Firefox the breakaway success that the Suite never was.
But really that just emphasizes how much Firefox depends on the entire Mozilla project, with its thousands of sometime developers and probably a few dozens of real core superstars. That's the real story here, but so far the media has chosen not to cover it.
Apps based on the Mozilla codebase (Firefox, Mozilla Suite, Thunderbird, Camino, Sunbird, NVu, etc.) are developed on a trunk-and-branch system. The "trunk" development stream is where all the heavy lifting and generic improvements to the core components get done. The core components all those apps share include things like Gecko (XHTML/CSS layout engine and DOM), Necko (networking), SpiderMonkey (Javascript engine), XUL (cross-platform graphical toolkit; not used by Camino), and many more. In addition to these shared components, there is of course app-specific code for each application, implementing that app's interface, features, bug-fixes, etc.
A few months before an app hits a milestone release intended for end-users (i.e. Mozilla Suite 1.8, Firefox 1.1, etc.), a "branch" will be cut from a snapshot of the trunk. Checkins to the branch are meant to get the app to release quality: bug-fixes, interface tweaks, cutting features that aren't quite ready for prime time, rushing in low-risk features with a big impact in end-user usability. (Meantime, checkins to the trunk continue as normal.) The branch will progress through some number of alpha releases, beta releases, and release candidates before culminating in a final point release. Then the branch gets shut down, the applicable bug fixes are merged back into the trunk code, and the process starts again.
Now, at any point you can checkout the entire trunk from CVS and, depending on a couple parameters in your build script, compile it into Firefox, or Mozilla Suite, or Thunderbird or whatever. (Or you can download a nightly trunk build of Firefox or the Suite.) But what you get is by definition in pre-alpha state; you might end up with half-baked features, features not matched up with the UI, and so forth. So trunk builds are mostly just useful for developers (whereas branch builds are useful for both developers and people doing QA).
Lately there's been more divergence between Firefox/Thunderbird and Mozilla Suite than normal because Firefox 0.9-1.0 and Thunderbird 0.7-1.0 were all cut from the same long-lived (7 months or so) branch, which was intended to allow them to get to 1.0 quality. Indeed the major work for the 1.1 releases is just to re-sync them with the trunk. But the plan is for shorter branches from here on out, at least until the 2.0 push.
So to answer your questions: there is a common core project, and most of the core components are shared, although they become out of sync on the branches. It's an open source project, so bugs and features get attention depending on what developers (or their employers) are interested in. It is indeed a point of contention that Firefox and Thunderbird increasingly tend to get more development resources than the Suite, but they both get to take advantage of improvements to the core components. And in that sense, at least, the codebases are not fragmenting; instead they're becoming more similar after a relatively long-lived divergence.