Software not specifically compiled for 64bit --- i.e., x86 code --- runs on the Itanium's x86 emulation layer at about the speed of a Pentium 100. This is abysmal --- an all-software emulator could probably do better.
Yeah, but the Itanium's x86 compatibility mode runs at about the speed of a Pentium 100. Macs can probably run existing Windows software faster than that using SoftPC. Seriously.
Galeon etc are fine web browser shells but they don't provide nearly as much UI as Mozilla does --- especially if you include Mozilla Mailnews, Composer, etc. Making UI for all that stuff is a lot of work. So it's hard to say for sure that it would have been less work to do independent native UIs.
Galeon etc also use Mozilla's widgets in their content areas for HTML widgets... getting native widgets to work there is hard because they have to be stylable with CSS, work with the Javascript/DOM event model, etc. Even IE doesn't use native widgets there. So a lot of the work behind XUL had to be done anyway.
It's great that the native UIs are being done. But even with hindsight it's hard to say whether the decision to go with XUL was clearly right or wrong.
Of course, going forward, having XUL around is pretty cool.
The telcos have a huge reason to drive DSL installs --- because the cable companies are taking over the Internet access market, and if they win completely and install VoIP, the telcos just go away as far as residential services are concerned.
The telcos are probably too stupid and/or evil to see this, but the motivation is there.
Simple, read the article or other comments in this Slashdot thread. When you're typing a password, you're sending single characters and the server isn't sending any echo back. That is easy to detect by packet sniffing.
SRP doesn't help here at all. The attack here is when you're logged into machine X using SSH and then you type a password to be used by machine X to log into machine Y. SRP does not help you securely get the password text to machine X.
You should read the paper. It's easy to see when people are typing passwords because the client is sending characters but the server is not echoing them back.
It's really hard to work out a good scheme to do this. The problem is that the user wants good interactive response so when they type a character, you have to send something right away. You can send a lot of garbage as well, but how do you make sure that the attacker can't tell the difference between garbage and the real data? Probably only by sending garbage constantly! That would massively increase the bandwidth requirements for SSH.
SSH2 is also vulnerable to MITM attacks if you don't know the server key or key fingerprint. OTOH, if you do have the server key, then in SSH1 clients (such as TTSSH) a MITM attack will trigger a warning that the "host key has changed". In TTSSH the default option in such a situation is to disconnect.
SSH2 doesn't have any magic that makes PKI easy. Anyone who tells you otherwise is trying to sell you something.
This is about passwords that you type in the course of an SSH session, NOT the initial password that logs you into SSH. That initial password is not vulnerable to timing-based traffic analysis because it is all sent in one packet.
The claim was that Konq's support for CSS2 is "practically complete". If the poster meant "Konq's support for the parts of CSS2 that people actually are using on Websites today is practically complete", then that would certainly be more credible, but that's not what they said.
(Note that few Web designers will use features that are not supported by browsers, so it's not good enough to implement what people are currently using and then say "OK, that's complete support"... we'd never make progress.)
Then there's the question of whether these features have simply been "implemented" or whether they've actually been debugged along with all their interactions with other parts of the system. That's actually where 80% of the work is. Jeff Baker seems to think the debugging is lagging...
Actually I'm incredibly impressed with Konqueror and its developers. They're doing a great job. They don't need advocacy that plays loose with the facts.
"overflow: scroll"... "visibility: collapse"... "text-align: justify"... these are fundamental CSS2 features, not just bells and whistles. Get those working then we'll talk.
<html><head><style>.CL { display: none; }</style>
<body><p class="cl">Hello world</body></html>
IE incorrectly treats class selectors as case-insensitive. This is one of many many bugs in IE's CSS support.
Re:This guy needs to develop some aethestic sense
on
Linux: Browser Wars
·
· Score: 2
Most of the composer code is required to support mailnews and CSS-styled text fields. The composer UI isn't that much extra, so getting rid of it wouldn't save much.
Re:Netscape 4.7x is it until Mozilla 1.0?
on
Linux: Browser Wars
·
· Score: 2
Netscape 4.x does suck in many ways. However, empty table cells not rendering the background color is BY DESIGN. There has been plenty of discussion about this in Mozilla; the consensus is that the W3C seems to require it, plus it is a useful feature --- it's easy enough to add an to get the background to render, but if empty cells drew the backround, there would be no way to make the background NOT render.
> Soon you'll have different browsers in the Linux
> world to those found in the corporate mainstream.
It's really the same browser. Same code base, so everyone has a common interest in improving it. Same support for standards, so presenting a united front to Web developers (this includes Konqueror and Opera too as a matter of fact).
The only significant difference from Netscape's point of view is that they lose revenue from the buttons and bookmarks they ship with their branded browser.
Mozilla has LDAP address auto-complete checked in and working now, although the UI isn't all there yet. More LDAP stuff is on the wap.
Re:0.9: The "Fuck Unix, We Wanna Be Microsoft" Bra
on
Mozilla 0.9 Out
·
· Score: 2
You, or possibly your machine, are on serious crack. 0.9 is way faster than 0.8.1 on Unix for most people.
BTW 0.9.1 will be a LOT faster and smaller than 0.9. Some major pieces of work have already landed or are about to land:
-- XPCDOM (slightly faster across the board, >2MB space saved on startup)
-- "Paint throttling" (~10% speedup on page loads)
-- HTTP rework (~10% page load speedup, sometimes more)
-- gcc -O2 on Linux (~10% page load speedup)
Slashdot Mirror
Software not specifically compiled for 64bit --- i.e., x86 code --- runs on the Itanium's x86 emulation layer at about the speed of a Pentium 100. This is abysmal --- an all-software emulator could probably do better.
= 20 4&Page=8
http://athena.tweakers.net/reviews.dsp?Document
Yeah, but the Itanium's x86 compatibility mode runs at about the speed of a Pentium 100. Macs can probably run existing Windows software faster than that using SoftPC. Seriously.
NT drove the Alpha in 32-bit mode. That doesn't count.
> Don't listen to anyone who says AOL's buyout has derailed the Mozilla
> project. They're clearly not taking an active role at all.
You mean, except for the 50+ full time AOL employees who are doing coding and QA for Mozilla.
Galeon etc are fine web browser shells but they don't provide nearly as much UI as Mozilla does --- especially if you include Mozilla Mailnews, Composer, etc. Making UI for all that stuff is a lot of work. So it's hard to say for sure that it would have been less work to do independent native UIs.
... getting native widgets to work there is hard because they have to be stylable with CSS, work with the Javascript/DOM event model, etc. Even IE doesn't use native widgets there. So a lot of the work behind XUL had to be done anyway.
Galeon etc also use Mozilla's widgets in their content areas for HTML widgets
It's great that the native UIs are being done. But even with hindsight it's hard to say whether the decision to go with XUL was clearly right or wrong.
Of course, going forward, having XUL around is pretty cool.
The telcos have a huge reason to drive DSL installs --- because the cable companies are taking over the Internet access market, and if they win completely and install VoIP, the telcos just go away as far as residential services are concerned.
The telcos are probably too stupid and/or evil to see this, but the motivation is there.
Simple, read the article or other comments in this Slashdot thread. When you're typing a password, you're sending single characters and the server isn't sending any echo back. That is easy to detect by packet sniffing.
Unfortunately, 100ms of latency is generally considred intolerable for interactive applications.
SRP doesn't help here at all. The attack here is when you're logged into machine X using SSH and then you type a password to be used by machine X to log into machine Y. SRP does not help you securely get the password text to machine X.
You should read the paper. It's easy to see when people are typing passwords because the client is sending characters but the server is not echoing them back.
It's really hard to work out a good scheme to do this. The problem is that the user wants good interactive response so when they type a character, you have to send something right away. You can send a lot of garbage as well, but how do you make sure that the attacker can't tell the difference between garbage and the real data? Probably only by sending garbage constantly! That would massively increase the bandwidth requirements for SSH.
SSH2 is also vulnerable to MITM attacks if you don't know the server key or key fingerprint. OTOH, if you do have the server key, then in SSH1 clients (such as TTSSH) a MITM attack will trigger a warning that the "host key has changed". In TTSSH the default option in such a situation is to disconnect.
SSH2 doesn't have any magic that makes PKI easy. Anyone who tells you otherwise is trying to sell you something.
The initial password length is not leaked if your client pads the password. Most SSH1 clients are now doing this.
This is about passwords that you type in the course of an SSH session, NOT the initial password that logs you into SSH. That initial password is not vulnerable to timing-based traffic analysis because it is all sent in one packet.
The claim was that Konq's support for CSS2 is "practically complete". If the poster meant "Konq's support for the parts of CSS2 that people actually are using on Websites today is practically complete", then that would certainly be more credible, but that's not what they said.
... we'd never make progress.)
(Note that few Web designers will use features that are not supported by browsers, so it's not good enough to implement what people are currently using and then say "OK, that's complete support"
Then there's the question of whether these features have simply been "implemented" or whether they've actually been debugged along with all their interactions with other parts of the system. That's actually where 80% of the work is. Jeff Baker seems to think the debugging is lagging...
Actually I'm incredibly impressed with Konqueror and its developers. They're doing a great job. They don't need advocacy that plays loose with the facts.
"overflow: scroll" ... "visibility: collapse" ... "text-align: justify" ... these are fundamental CSS2 features, not just bells and whistles. Get those working then we'll talk.
<html><head><style>.CL { display: none; }</style>
<body><p class="cl">Hello world</body></html>
IE incorrectly treats class selectors as case-insensitive. This is one of many many bugs in IE's CSS support.
Most of the composer code is required to support mailnews and CSS-styled text fields. The composer UI isn't that much extra, so getting rid of it wouldn't save much.
Netscape 4.x does suck in many ways. However, empty table cells not rendering the background color is BY DESIGN. There has been plenty of discussion about this in Mozilla; the consensus is that the W3C seems to require it, plus it is a useful feature --- it's easy enough to add an to get the background to render, but if empty cells drew the backround, there would be no way to make the background NOT render.
That would be Mozilla then.
r na l.open","noAccess");
e nt s/configPolicy.html
user_pref("capability.policy.default.windowinte
http://www.mozilla.org/projects/security/compon
LDAP address autocomplete has landed in Mozilla just recently. More LDAP support is coming fast.
> Soon you'll have different browsers in the Linux
> world to those found in the corporate mainstream.
It's really the same browser. Same code base, so everyone has a common interest in improving it. Same support for standards, so presenting a united front to Web developers (this includes Konqueror and Opera too as a matter of fact).
The only significant difference from Netscape's point of view is that they lose revenue from the buttons and bookmarks they ship with their branded browser.
LDAP address autocomplete has landed. More is on the way.
Mozilla has LDAP address auto-complete checked in and working now, although the UI isn't all there yet. More LDAP stuff is on the wap.
You, or possibly your machine, are on serious crack. 0.9 is way faster than 0.8.1 on Unix for most people.
BTW 0.9.1 will be a LOT faster and smaller than 0.9. Some major pieces of work have already landed or are about to land:
-- XPCDOM (slightly faster across the board, >2MB space saved on startup)
-- "Paint throttling" (~10% speedup on page loads)
-- HTTP rework (~10% page load speedup, sometimes more)
-- gcc -O2 on Linux (~10% page load speedup)