The NZ census held earlier this year supported Web-based online filing. It was a very clean UI (some touches of DHTML to streamline the interface), worked in IE, Firefox, Safari and Opera, and overall seemed to work very well indeed.
> "Certainly one thing is clear--even with Atlas, the browser's > capabilities simply don't match those of Windows itself," Lhotka > said. "The more you want your Web pages to act like Windows, the > more expensive it becomes. Atlas helps ease some of that cost and > pain, but my feeling is that ultimately Atlas is a bridge between > simple HTML and WPF [Windows Presentation Foundation], filling an > important niche."
I've been in his shoes... the PR people write the quote for you and ask, "is this OK?"
Microsoft's campaign to replace the Web with WPF has begun.
> I don't want to see it become "what you have to use whether you like it or not", because > we've been down that road.
Well sure. But there are two things that make Firefox different from IE so Firefox domination wouldn't be so bad: 1) The Firefox team is fiercely committed to supporting Web standards. 2) It's open source. If any competitor wants challenge Firefox they can start by copying our code and then taking it in whatever direction they want. It's kinda hard to sustain an evil monopoly in the face of that.
This is another Andrew Orlowski rant. He has a chip on his shoulder on a whole range of subjects and is generally not to be trusted.
For example, he has a vendetta against Google, and seems to regard Google as a less trustworthy company than even Microsoft. Google certainly isn't perfect but it sure doesn't have Microsoft's track record.
Please file bugs in Mozilla's Bugzilla. We really want to fix as many SVG compatibility issues as we can for Firefox 1.5 and we need people with SVG content to test it in Firefox.
Intel spent billions marketing IA64. They gave away lots of expensive hardware to developers. They used their monopoly muscle, and cash, to strongarm all the big industry software and hardware manufacturers into supporting it. They persuaded several companies to abandon their own architectures and bet on IA64 for the future. They ensured that analysts everywhere were united in hailing IA64 as the wave of the future. It COULD NOT have been pushed harder.
It's a measure of just how bad the architecture is that IA64 has failed IN SPITE of all that.
> There is no question in my mind that the > 501(c)(3) tax-exempt public charity status is > not the ideal vehicle for laundering Google's > lucre.
I don't know why you'd have a problem with "laundering Google's lucre" when the money goes to develop a great open source web browser and break Microsoft's grip on the web.
> But then Google defused this particular bomb by > doing a hand job on their algorithm in July, > 2004.
How exactly do you know it was done by hand? Someone at Google must have told you, I guess, otherwise you could not know. Did they?
> We can probably expect IE 7.5 or 8 about the > time of Longhorn next year. It may even have a > 7.5 sometime in the spring and 8 in the fall, > though I think that's unlikely.
What are you talking about? They've said that IE7 will ship on Longhorn. So you're suggesting they'll be at IE7.5 or 8 on WinXP and 7 on Longhorn? No way.
> I fully expect that by the time Longhorn ships, > IE will be as standards compbliant as Firefox > is, though i've been known to be wrong before.
FF 1.5 will not pass Acid2. This is not the right time in our release schedule to fix those kinds of bugs. We'll pass Acid2 in the next major version of FF after that.
> I also expect that this will be abused by > unscrupulous websites who want to run up their ad > revenue by having people preload a page full of > ads.
They can already do this using hidden IFRAMEs, and it works on all browsers. Nothing new here, move along.
> That's a flaw in firefox's prefetching logic, not > in site-designers' use of rel=next, which was > never intended to be used to indicate links the > user was most likely to follow.
Actually if you read the comments, you'll notice that the HTML4 spec specifically says that rel="next" may be used for prefetching. So Mozilla is simply following the spec here.
Others have already corrected this comment but I feel I have to correct it too, because the notion is widespread and quite wrong.
Often the compiler simply CANNOT KNOW much about what is going to happen at run time. You should not expect an "omniscient compiler" to be developed any more than you should expect "omniscient weather forecasting" to be developed. In the absence of good information about the future, you have to be able to dynamically adapt to changing conditions. JIT compilers can do this to some extent, but generally JIT profile analysis and recompilation won't happen as quickly or efficiently as hardware implementations of adaptive features.
Slashdot Mirror
The NZ census held earlier this year supported Web-based online filing. It was a very clean UI (some touches of DHTML to streamline the interface), worked in IE, Firefox, Safari and Opera, and overall seemed to work very well indeed.
> Is this in any way different than when Microsoft bundled IE to hurt Netscape? If so,
> can someone explain it to me?
Sure. Are major OEMs being threatened with loss of their Windows licenses if they ship the Adobe software preinstalled? No.
IE6 runs on MIPS/ARM?
> Instead of fixing incessant crashes and debilitating memory leaks
That's an insult to the developers who have spent hundreds of hours fixing crashes and memory leaks and other polish issues.
Your message is also completely off base given that the article is about features being cut to allow more focus on polish.
> "Certainly one thing is clear--even with Atlas, the browser's
... the PR people write the quote for you and ask, "is this OK?"
> capabilities simply don't match those of Windows itself," Lhotka
> said. "The more you want your Web pages to act like Windows, the
> more expensive it becomes. Atlas helps ease some of that cost and
> pain, but my feeling is that ultimately Atlas is a bridge between
> simple HTML and WPF [Windows Presentation Foundation], filling an
> important niche."
I've been in his shoes
Microsoft's campaign to replace the Web with WPF has begun.
Now we just need someone to take the Eclipse JDT and convert it to an equivalent toolset for C#.
We should have hyphenation working in Gecko 1.9 which will hopefully come out near the end of 2006.
> I don't want to see it become "what you have to use whether you like it or not", because
> we've been down that road.
Well sure. But there are two things that make Firefox different from IE so Firefox domination wouldn't be so bad:
1) The Firefox team is fiercely committed to supporting Web standards.
2) It's open source. If any competitor wants challenge Firefox they can start by copying our code and then taking it in whatever direction they want. It's kinda hard to sustain an evil monopoly in the face of that.
Can't you wrap it in an with a transform?
This is another Andrew Orlowski rant. He has a chip on his shoulder on a whole range of subjects and is generally not to be trusted.
For example, he has a vendetta against Google, and seems to regard Google as a less trustworthy company than even Microsoft. Google certainly isn't perfect but it sure doesn't have Microsoft's track record.
1.0.x is a security branch now. 1.0.7 will only get security fixes.
1.5 has thousands of bug fixes. Try it.
We do need to do some work to make the browser more responsive, especially with plugins.
Please file bugs in Mozilla's Bugzilla. We really want to fix as many SVG compatibility issues as we can for Firefox 1.5 and we need people with SVG content to test it in Firefox.
> had it been pushed correctly
Intel spent billions marketing IA64. They gave away lots of expensive hardware to developers. They used their monopoly muscle, and cash, to strongarm all the big industry software and hardware manufacturers into supporting it. They persuaded several companies to abandon their own architectures and bet on IA64 for the future. They ensured that analysts everywhere were united in hailing IA64 as the wave of the future. It COULD NOT have been pushed harder.
It's a measure of just how bad the architecture is that IA64 has failed IN SPITE of all that.
The problem is not that the IA64 compilers have a few bugs.
The problem is that the IA64 architecture asks compilers to DO THE IMPOSSIBLE.
> There is no question in my mind that the
> 501(c)(3) tax-exempt public charity status is
> not the ideal vehicle for laundering Google's
> lucre.
I don't know why you'd have a problem with "laundering Google's lucre" when the money goes to develop a great open source web browser and break Microsoft's grip on the web.
> But then Google defused this particular bomb by
> doing a hand job on their algorithm in July,
> 2004.
How exactly do you know it was done by hand? Someone at Google must have told you, I guess, otherwise you could not know. Did they?
> We can probably expect IE 7.5 or 8 about the
> time of Longhorn next year. It may even have a
> 7.5 sometime in the spring and 8 in the fall,
> though I think that's unlikely.
What are you talking about? They've said that IE7 will ship on Longhorn. So you're suggesting they'll be at IE7.5 or 8 on WinXP and 7 on Longhorn? No way.
> I fully expect that by the time Longhorn ships,
> IE will be as standards compbliant as Firefox
> is, though i've been known to be wrong before.
Nice troll.
iCab passes because they use Webcore from Safari as their rendering engine.
FF 1.5 will not pass Acid2. This is not the right time in our release schedule to fix those kinds of bugs. We'll pass Acid2 in the next major version of FF after that.
> So I think that sums most of 'em.
You must be joking. There's a *mountain* of other bugs in IE. These are just the most painful and well known ones.
That sort of history caching is coming in Firefox 1.1.
Something similar to Opera's history caching scheme is implemented in Firefox 1.1.
It probably doesn't affect stats though, because most people are counting sessions, not fetches.
Also, Google already has some kind of porn checker for their safe-search service. They could use that to avoid having users prefetch porn.
> I also expect that this will be abused by
> unscrupulous websites who want to run up their ad
> revenue by having people preload a page full of
> ads.
They can already do this using hidden IFRAMEs, and it works on all browsers. Nothing new here, move along.
> That's a flaw in firefox's prefetching logic, not
> in site-designers' use of rel=next, which was
> never intended to be used to indicate links the
> user was most likely to follow.
Actually if you read the comments, you'll notice that the HTML4 spec specifically says that rel="next" may be used for prefetching. So Mozilla is simply following the spec here.
Others have already corrected this comment but I feel I have to correct it too, because the notion is widespread and quite wrong.
Often the compiler simply CANNOT KNOW much about what is going to happen at run time. You should not expect an "omniscient compiler" to be developed any more than you should expect "omniscient weather forecasting" to be developed. In the absence of good information about the future, you have to be able to dynamically adapt to changing conditions. JIT compilers can do this to some extent, but generally JIT profile analysis and recompilation won't happen as quickly or efficiently as hardware implementations of adaptive features.