AOL has a few very good reasons to want to integrate Mozilla into the AOL client.
First, if they sell a custom box running AOL on Linux, the profit is all AOL's.
Second, relying on IE and Windows creates a massive strategic weakness for AOL. Microsoft can and does try to direct users to Microsoft content rather than AOL/TW content. Furthermore, AOL is vulnerable to whatever new tricks may MS decide to roll into IE. Depending on your fiercest competitor (who wants you dead) for the most important chunk of your software, with no plan B, would just be suicidal.
Third, AOL-TV. Mozilla lets AOL move in directions that Microsoft doesn't want to go, or more likely doesn't want AOL to go.
Re:Can we a "Ask the Mozilla team" interview?
on
Send Some Mo' Zilla
·
· Score: 2
1) Mozilla is divided into separate packages. When you run the installer, you can choose which parts to install; it will download and install just the parts you choose.
2) Using Gecko to render the UI makes it basically impossible to use native widgets and native themes, and also made it easy to implement Mozilla themes. So that's what they did.
Using Gecko to render the UI is a good idea because it means Mozilla developers only have to write the UI once (in XUL). You can also do a lot of UI stuff in XUL that you can't easily do using all platform UI toolkits (e.g. custom icons in menus, dynamically extending dialog boxes).
Also, because Gecko supports CSS, Gecko widgets can naturally be styled using CSS, which is something Web developers really want. Even IE uses its own widget implementation instead of the Win32 widgets, for exactly this reason. Most platform widget sets don't come anywhere close to supporting this.
Some people do want support for native widgets and themes more than any of these other benefits. Mozilla developers are listening and are definitely interested in providing native widgets as an option; we have some ideas about how to do it.
Re:How it CSS died is irrelevant - its dead
on
Send Some Mo' Zilla
·
· Score: 2
This is complete and utter rubbish.
Every browser vendor is working hard on improving their CSS support.
If you want to style documents, what are the alternatives to using CSS? Today people use TABLEs, FONT tags and other presentational markup, but that's not nearly as powerful or easy to use as CSS. As the baseline level of CSS support in GUI browsers increases, designers will use it more and more. They'd be crazy not to.
The other alternative is XML+XSLT+XSL-FO. But this is far in the future and there are unresolved questions that so far make it a less than complete solution (e.g. how to support dynamic documents).
IE5's standards compliance is actually fairly good. You can do a lot of useful DOM/DHTML stuff based on W3C standards that will work fine in IE5 and Mozilla.
As Mozilla-based browsers become more and more widely used, the pressure for Web developers to use real standards will increase. This is good news for all browser developers except Microsoft. But it certainly won't happen overnight.
The problem is that once the monopoly gets ahead, they stop innovating because innovation is expensive. You can see this with Office and then Win9x series.
IBM's working on adding OJI support to their JVM. They kind of have to because Mozilla is the only full-featured browser that will run on OS/2 and AIX.
It sniffs the DOCTYPE. If it looks like a "modern" document, then it applies standards-compliant rendering, otherwise it applies "backwards compatible" rendering (called "quirks mode").
For most pages out there, applying standards-compliant rendering would produce a real mess.
Some people built a thing called Forumzilla, which is pretty close to a Slashdot-cruiser written in XUL. I haven't heard of any plans to roll it into the standard Mozilla distribution, though.
Going back should return you to the correct scroll position. That feature broke recently; it has been fixed, but maybe not in time for the official M18 build.
Like the other poster said, if you really want to configure the way Mozilla renders Web pages, go wild with user style sheets. Try something like this:
:link { text-decoration: none; }
User CSS really provides the ultimate customizable browsing experience.
Re:When Cryptography Becomes a Political Attack...
on
SDMI Cracked Too Soon
·
· Score: 2
Also, there is no limit on the number of attacks. Some people have expressed the fear that attacking now helps them build a stronger SDMI. That is rubbish, because there is no technology for building a stronger SDMI. Whatever they release, we will break.
Basically two things can happen from here:
-- Industry sinks millions into "SDMI Mark II", it's immediately broken, and they wasted a lot of money just as they would have if no-one had cracked SDMI Mark I.
-- Industry eventually gives up on SDMI and purchases more legislation from Congress instead.
Cracking it now increases the likelihood of the latter happening soon, but it would have happened eventually anyway.
> Is it inconcivable to build a player that cannot
> be disassembled?
We're talking about software players here, so yes, it's inconceivable. I'll bet my PhD on it.
Some of the best CS theory profs around have given some thought to what it would mean for a program to be effectively "undisassemblable". They've had a hard time coming up with a definition that doesn't just reduce to the empty set. AFAIK, their current best definition hasn't yet been shown to reduce to the empty set, but no-one's been able to construct an undisassemblable program either.
In CS theory the action is at the frequent conferences, FOCS and STOCS in particular. Most results are not extensively publicised before appearing at such conferences.
CS is not like the natural sciences where journals are the key. In most branches of CS no-one really cares about journals, the action is all at conferences.
Re:Huge crytography implications!
on
Does P = NP?
·
· Score: 2
The implications are much huger than that. In fact, if P=NP, then mathematics as we know it is over, to be replaced by a little art and a lot of engineering. Here's why:
Suppose I have a theorem X. I want to know if it's true, and if so, what the proof is. Now, if I have a proof, then I can certainly check it in time polynomial in the size of the proof. Therefore, because P=NP, I can also check in polynomial time whether there is any proof of X shorter than some specified size bound.
Of course, it may be that the shortest proof of X is larger than the specified size bound. But if we set the bound large enough, then we can be pretty confident that no human would ever find the proof. Therefore, by running our algorithm on X and !X, we can get three possible answers:
"Yes, X is true and here's the proof of X"
"No, X is false and here's the proof of !X"
"X may or may not be true, but you'll never be able to prove it either way"
Useful, huh? If the polynomial running time in terms of the size bound is high degree, it might take a while for computers to overtake our mathematicians, but it would happen.
This idea is actually not new. Godel basically posed it to Von Neumann in the 50's --- long before the concepts of P and NP became currrent.
Re:This is an incorrect definition of NP
on
Does P = NP?
·
· Score: 3
Sorry, factoring is not known to be NP-hard or NP-complete.
Unless there's been a HUGE breakthrough which I didn't hear about, it is not known whether a quantum computer can solve NP-complete problems in polynomial time. None of the "hard" problems (like factoring) that are known to be amenable to quantum solutions are actually NP-complete.
> With the online retailers, we must discuss the
> need to properly notify consumers outside
> the region 1 territories that the disc may not
> play in their player before the disc is
> purchased. The customer dissatisfaction and
> returns risk is significant if this is not done.
Some "innocent bystanders" are likely to get burned.
Yep. Since ML supports paramteric polymorphism but not subtyping, and CLR supports subtyping but not parameteric polymorphism, I'll bet they had a great time fitting ML in there.
I also noticed that the "Eiffel#" port amounted to "throw away the bits of Eiffel (e.g. MI) that don't fit into C#".
I should clarify that most IE scripts *won't* work off the bat because they use non-standard features (especially document.all). They need to be modified to use the standards-based way of doing things (e.g. getElementById).
Mozilla supports the W3C standard DOM (version 1 and most of version 2), which is very similar to what's in IE5. For most of the stuff people want to do, you can write one script that will work in Mozilla and IE5.
What they did with Crypto AG was just introduce flaws that made the system easy to crack if you knew what you were looking for. Very hard to spot. This gets around your traffic analysis issue in three possible ways:
-- You send something encrypted over the wire, they sniff it and are able to recover the plaintext.
-- You keep something encrypted in your office, if they decide you might be important then they break in, copy and decrypt.
-- You keep something on your computer, if they decide you might be important then they break in over the Internet and copy your data.
Most people are now seeing Mozilla performance at least as fast as NS 4.x for any value of x, at least in raw rendering speed. There are several reasons you might now be, insufficient memory being the most likely one.
All you have to do is to run the installer to see that Mozilla is modular, and you can choose which modules to download and install. I don't know why I keep seeing endless Slashdot ranting denying this.
> Instead of building on the platform-neutral
> framework that Mozilla already had, they built
> their own platform-neutral toolkit.
Mozilla did not already have a "platform-neutral framework". What are you talking about?
Slashdot Mirror
AOL has a few very good reasons to want to integrate Mozilla into the AOL client.
First, if they sell a custom box running AOL on Linux, the profit is all AOL's.
Second, relying on IE and Windows creates a massive strategic weakness for AOL. Microsoft can and does try to direct users to Microsoft content rather than AOL/TW content. Furthermore, AOL is vulnerable to whatever new tricks may MS decide to roll into IE. Depending on your fiercest competitor (who wants you dead) for the most important chunk of your software, with no plan B, would just be suicidal.
Third, AOL-TV. Mozilla lets AOL move in directions that Microsoft doesn't want to go, or more likely doesn't want AOL to go.
1) Mozilla is divided into separate packages. When you run the installer, you can choose which parts to install; it will download and install just the parts you choose.
2) Using Gecko to render the UI makes it basically impossible to use native widgets and native themes, and also made it easy to implement Mozilla themes. So that's what they did.
Using Gecko to render the UI is a good idea because it means Mozilla developers only have to write the UI once (in XUL). You can also do a lot of UI stuff in XUL that you can't easily do using all platform UI toolkits (e.g. custom icons in menus, dynamically extending dialog boxes).
Also, because Gecko supports CSS, Gecko widgets can naturally be styled using CSS, which is something Web developers really want. Even IE uses its own widget implementation instead of the Win32 widgets, for exactly this reason. Most platform widget sets don't come anywhere close to supporting this.
Some people do want support for native widgets and themes more than any of these other benefits. Mozilla developers are listening and are definitely interested in providing native widgets as an option; we have some ideas about how to do it.
This is complete and utter rubbish.
Every browser vendor is working hard on improving their CSS support.
If you want to style documents, what are the alternatives to using CSS? Today people use TABLEs, FONT tags and other presentational markup, but that's not nearly as powerful or easy to use as CSS. As the baseline level of CSS support in GUI browsers increases, designers will use it more and more. They'd be crazy not to.
The other alternative is XML+XSLT+XSL-FO. But this is far in the future and there are unresolved questions that so far make it a less than complete solution (e.g. how to support dynamic documents).
IE5's standards compliance is actually fairly good. You can do a lot of useful DOM/DHTML stuff based on W3C standards that will work fine in IE5 and Mozilla.
As Mozilla-based browsers become more and more widely used, the pressure for Web developers to use real standards will increase. This is good news for all browser developers except Microsoft. But it certainly won't happen overnight.
The problem is that once the monopoly gets ahead, they stop innovating because innovation is expensive. You can see this with Office and then Win9x series.
IBM's working on adding OJI support to their JVM. They kind of have to because Mozilla is the only full-featured browser that will run on OS/2 and AIX.
It sniffs the DOCTYPE.
> Now, I don't need a mail client, but if I use
> Mozilla there will be one there waiting for me,
> regardless of whether I want it or not.
Unless you uncheck "Mailnews" when you install Mozilla.
It sniffs the DOCTYPE. If it looks like a "modern" document, then it applies standards-compliant rendering, otherwise it applies "backwards compatible" rendering (called "quirks mode").
For most pages out there, applying standards-compliant rendering would produce a real mess.
Some people built a thing called Forumzilla, which is pretty close to a Slashdot-cruiser written in XUL. I haven't heard of any plans to roll it into the standard Mozilla distribution, though.
Going back should return you to the correct scroll position. That feature broke recently; it has been fixed, but maybe not in time for the official M18 build.
Like the other poster said, if you really want to configure the way Mozilla renders Web pages, go wild with user style sheets. Try something like this:
:link { text-decoration: none; }
User CSS really provides the ultimate customizable browsing experience.
Also, there is no limit on the number of attacks. Some people have expressed the fear that attacking now helps them build a stronger SDMI. That is rubbish, because there is no technology for building a stronger SDMI. Whatever they release, we will break.
Basically two things can happen from here:
-- Industry sinks millions into "SDMI Mark II", it's immediately broken, and they wasted a lot of money just as they would have if no-one had cracked SDMI Mark I.
-- Industry eventually gives up on SDMI and purchases more legislation from Congress instead.
Cracking it now increases the likelihood of the latter happening soon, but it would have happened eventually anyway.
> Is it inconcivable to build a player that cannot
> be disassembled?
We're talking about software players here, so yes, it's inconceivable. I'll bet my PhD on it.
Some of the best CS theory profs around have given some thought to what it would mean for a program to be effectively "undisassemblable". They've had a hard time coming up with a definition that doesn't just reduce to the empty set. AFAIK, their current best definition hasn't yet been shown to reduce to the empty set, but no-one's been able to construct an undisassemblable program either.
In CS theory the action is at the frequent conferences, FOCS and STOCS in particular. Most results are not extensively publicised before appearing at such conferences.
CS is not like the natural sciences where journals are the key. In most branches of CS no-one really cares about journals, the action is all at conferences.
The implications are much huger than that. In fact, if P=NP, then mathematics as we know it is over, to be replaced by a little art and a lot of engineering. Here's why:
Suppose I have a theorem X. I want to know if it's true, and if so, what the proof is. Now, if I have a proof, then I can certainly check it in time polynomial in the size of the proof. Therefore, because P=NP, I can also check in polynomial time whether there is any proof of X shorter than some specified size bound.
Of course, it may be that the shortest proof of X is larger than the specified size bound. But if we set the bound large enough, then we can be pretty confident that no human would ever find the proof. Therefore, by running our algorithm on X and !X, we can get three possible answers:
"Yes, X is true and here's the proof of X"
"No, X is false and here's the proof of !X"
"X may or may not be true, but you'll never be able to prove it either way"
Useful, huh? If the polynomial running time in terms of the size bound is high degree, it might take a while for computers to overtake our mathematicians, but it would happen.
This idea is actually not new. Godel basically posed it to Von Neumann in the 50's --- long before the concepts of P and NP became currrent.
Sorry, factoring is not known to be NP-hard or NP-complete.
Unless there's been a HUGE breakthrough which I didn't hear about, it is not known whether a quantum computer can solve NP-complete problems in polynomial time. None of the "hard" problems (like factoring) that are known to be amenable to quantum solutions are actually NP-complete.
Not necessarily. From the memo:
> With the online retailers, we must discuss the
> need to properly notify consumers outside
> the region 1 territories that the disc may not
> play in their player before the disc is
> purchased. The customer dissatisfaction and
> returns risk is significant if this is not done.
Some "innocent bystanders" are likely to get burned.
I'm pretty sure ODBC was invented by Microsoft. I used it for a while in '93-'94. They might have submitted it to X/Open later.
Yep. Since ML supports paramteric polymorphism but not subtyping, and CLR supports subtyping but not parameteric polymorphism, I'll bet they had a great time fitting ML in there.
I also noticed that the "Eiffel#" port amounted to "throw away the bits of Eiffel (e.g. MI) that don't fit into C#".
I should clarify that most IE scripts *won't* work off the bat because they use non-standard features (especially document.all). They need to be modified to use the standards-based way of doing things (e.g. getElementById).
Mozilla supports the W3C standard DOM (version 1 and most of version 2), which is very similar to what's in IE5. For most of the stuff people want to do, you can write one script that will work in Mozilla and IE5.
What they did with Crypto AG was just introduce flaws that made the system easy to crack if you knew what you were looking for. Very hard to spot. This gets around your traffic analysis issue in three possible ways:
-- You send something encrypted over the wire, they sniff it and are able to recover the plaintext.
-- You keep something encrypted in your office, if they decide you might be important then they break in, copy and decrypt.
-- You keep something on your computer, if they decide you might be important then they break in over the Internet and copy your data.
I know this is a troll, but still...
Most people are now seeing Mozilla performance at least as fast as NS 4.x for any value of x, at least in raw rendering speed. There are several reasons you might now be, insufficient memory being the most likely one.
All you have to do is to run the installer to see that Mozilla is modular, and you can choose which modules to download and install. I don't know why I keep seeing endless Slashdot ranting denying this.
> Instead of building on the platform-neutral
> framework that Mozilla already had, they built
> their own platform-neutral toolkit.
Mozilla did not already have a "platform-neutral framework". What are you talking about?