This time eight years ago, Linux 2.0 had just been released. The KDE project had only just been started and GNOME wouldn't exist for another year. We were on libc5, just recovering from the changeover from a.out to ELF, and the EGCS fork of GCC hadn't even happened yet, let alone been merged back into the main branch.
I don't think many authors of GPLed works would mind software of that vintage losing GPL protection by entering the public domain.
To use the over-hyped XML paradigm, standard tags would allow every IM vendor to talk with each other. Then more would use IM, allowing the vendors to add features and lower pricing (economy of scale).
Unfortunately, that means that the existing heavyweights (AOL, Microsoft, etc) lose a hell of a lot of control, so they are unlikely to support it. I'd expect them to compete with each other until it becomes clear that one is going to win, and then the others will throw their weight behind XMPP.
You are equating accessibility with discrimination.
We are talking about the Disability Discrimination Act.
Not helping is not the same as discriminating against.
You are right, but it isn't about Odeon "not helping". Websites start out mostly accessible by default. That's how HTML was designed. Odeon went to extra effort to add in code that was entirely aesthetic in nature, that locked out disabled people. If they hadn't taken those extra measures, their site would almost certainly be accessible to disabled people. That's what makes it discrimination and not "not helping". They discarded disabled people for badly-coded Javascript gimmicks.
PHP is a nice language, good for beginners. But it's complete lack of namespaces, half-arsed support for functional constructs (damn I hate having to write callback functions out seperately when they're one liners!), and schizophrenic api are slowly pushing me towards more well thought-out languages like Python.
I completely agree. The standard Python libraries are inconsistent in places, but nowhere near as bad as PHP's. PEAR alleviates this a little, but you might want to check out PiP (Python in PHP). It lets you use objects written in Python from within a PHP script.
Then I find that I can't tell what tab's what since the text it used for them was too big (and I never found a way to change it, even in the extra options extension).
You're right, I think that should be an option available through the UI. In the meantime, you can work around it by putting the following in your userChrome.css file and restarting the browser:
tab { font-size: 90%; }
This isn't meant as a troll, it's meant to prompt some serious thought. I'm a SysAdmin and I even had promblems in the install process (with extensions granted, but that's more than enough to kill off your average joe-user).
Joe-user shouldn't have to install a lot of extensions. What functionality that the "joe-users" use is missing from Firefox?
If a virus can edit the hosts file, it can tamper with HTTPS authentication. There is, however, extra danger from man-in-the-middle attacks and nameserver subversion.
What's sad is that Internet Explorer 6 was released about two and a half years ago, has had no new features added, and they still haven't finished fixing it.
Put the Windows Update site into the "local sites" zone or whatever Internet Explorer calls it. Set the "local sites" security to the same as the Internet zone, and then switch Active Scripting off in the Internet zone.
This effectively emulates the domain-specific Javascript settings in other browsers.
Now let us hope that there are no spoofing mechanisms discovered that result in users believing they're on one of the whitelisted sites to allow such installations.
Users can believe whatever they want, it's the browser that pays attention to the whitelist. And if a site can spoof which domain it is coming from, that opens up loads of security holes, not just this one.
Business types are afraid of OSS mostly for the fact that it's "unsupported." To them, support doesn't mean having developers on hand to fix problems so much as it does having someone to blame when things go wrong.
That's not true. It's all about managing business risks.
Having software you rely upon fail is a business risk. To make sure that risk doesn't become a problem, "business types" need to look at various factors, such as how likely it is to occur, how disastrous the results could be, and what actions they can take in the event of failure.
The damage that can be done from a security hole is pretty big. So you have to look at how likely it is to occur. Mozilla has show itself to be prone to less security holes than Internet Explorer by quite a wide margin. However, with any reasonably complex software, holes are bound to crop up from time to time, so you can't just say "Mozilla is more secure and that's the end of it".
Instead, you need to look at what kind of action you can take when a security hole is found to mitigate the risk. With Internet Explorer, you have to wait for Microsoft to fix the hole, test the fix, and then deploy it. With Mozilla, the same applies, except you also have the option of fixing it yourself.
Fixing it yourself is almost never the right option. Even if you have in-house developers on staff with experience in the relevent languages (which is very unlikely), they would almost certainly be completely unfamiliar with the Mozilla codebase. The chances of them opening up additional security holes or breaking important functionality when fixing the original security hole is a business risk in itself. So, generally speaking, most businesses will want to wait for the official Mozilla patch.
So you need to look at which organisation is more reliable at getting patches out. Mozilla might be faster, but Microsoft should probably be considered more dependable. After all, they have millions of clients in exactly the same situation as you, and the Mozilla developers can simply walk away from it if it proves too tough to fix.
So, comparing the business risks of using Internet Explorer and Mozilla really depends on which is more important to you - the dependability of being in the same boat as millions of others, or the speed at which Mozilla developers can get a patch out to you. It's got nothing to do with blame.
Why are you asking me? The specification is available to everyone. It says that negative margins are implementation-specific. I'm not sure what you mean by "negative border offsets", it's not normal CSS terminology. Are you talking about padding? The CSS 1 specification explicitly forbids negative padding.
That's not right. The actual string "shell:" is the protocol. Passing off just the protocol part of the URL would be useless. It would be like telling a web browser to go to "http:".
So far nothing really works as it should in all browsers - so I will simply follow where the money comes from: IE.
And please spare me the 'develop with web standards speach' - neither Moz, Firesomething nor Opera fully and properly support all CSS versions, DOM etc.... and let's not talk Java either.
Come off it. All the other major browsers support 99% of the CSS, DOM, etc specifications, so it's unreasonable to criticise Internet Explorer for scraping by with something like 50% support for them?
Nobody advocates authoring to the specifications, using each and every feature, and to hell with the browsers. What people actually advocate is authoring to the specifications, avoiding the troublesome areas that Internet Explorer can't cope with. The 99% support that the other major browsers offer is certainly adequate for that development method.
>These browsers are good bets from a security point now, but why would they be safe in 6 months, or a year?
Because they are designed with better security paradigms - they don't by default trust DATA as EXECUTIBLE CODE.
I thought that was the cause of the recent security hole in Mozilla? That it passed off URLs to be executed as long as the protocol wasn't in a blacklist?
This begins the question that has never really been answered. If an open source program becomes the dominant standard for a large number of desktop users, open source will be tested as never before. The code will be available for all, white hats and black hats.
That question was answered years ago. Open-source is used all over the place. Apache is the usual example. Its code has been available for years, it's far more popular than IIS, and yet it's had far less security holes and breakins compared with IIS.
Plus the government probably has thousands of backdoors installed
The code's there for you to look at. Feel free to point the backdoors out.
Re:Not ONLY Faster, lighter, but also IE-compatibl
on
Browser Wars 2004
·
· Score: 1
IE has one thing that no other browser has: it shows almos Every Single Page as it was intended by the designers.
That's because due to Internet Explorer's market share, web developers have no choice but to work around Internet Explorer's bugs or, if that's not possible, give up on certain effects completely. So the thing that makes Internet Explorer more popular is its popularity.
So, while MS does not respect W3C standards, the only way to compete with IE is being able to render the pages exactly like IE does.
Until then, we'll be in a IE driven web
No, making other browsers emulate Internet Explorer is what will drive us towards an Internet Explorer-driven web. What happens when Internet Explorer 6.5 comes out with a new set of behaviours? Other browsers will have to jump to reverse-engineer them and then implement them. And by that time, Internet Explorer 7 will be out, and so the cycle starts again...
Re:your enthusiasm is unwarranted
on
Browser Wars 2004
·
· Score: 4, Informative
They barely support CSSv1 correctly even in the latest IE, and anything later than that is totally haphazard.
Actually, Internet Explorer 6 gets CSS 1 almost completely right. I agree with the "haphazard" description of CSS 2 support though.
Don't forget that this has already bitten them.. MS did the good thing and implemented as much of CSS1 as was ready in IE5
Then the powers that be changed various bits for the final standard.. and MS put that standard in IE5.5
Internet Explorer 5.0 was released in March 1999. The CSS 1 specification was published on the 17th of December 1996, and had minor changes, which were published on the 11th of January 1999. Microsoft have employees in the CSS working group that is responsible for these specifications, so they knew about the changes well in advance of the rest of the world.
Let's not forget the five year old HTTP 1.1 and the eight year old PNG specifications that they still haven't implemented correctly. But it's not as if Microsoft have loads of resources to spare, is it? I mean, they are hardly the world's biggest software company!
I think you may be misinterpreting what Jezral is getting at.
Filename extensions have never been part of the WWW. Sure, you get URLs with dots in various places, but that doesn't mean anything. At least not in browsers that adhere to the specifications.
The HTTP specification, RFC 2616, explicitly states that web browsers may not attempt to guess a file type when a Content-Type header has been provided. Internet Explorer does, paying attention to what comes after dots in a URL and the first few bytes of a resource. That is flat-out incorrect behaviour.
The Content-Type header is more flexible and standardised than a random three letter extension on the end of a URL, and much easier to disambiguate by clients.
Microsoft seem to be fixing this issue a little with the service pack update, but to what extent is unknown - so far as their description of the behaviour is a little confusing.
Wanting this issue to be addressed by Microsoft is not the same as wanting to remove your file extensions from your OS.
It also means that non-power users will freak out when their banking websites or whatever that use valid popups stop working.
Which "valid popups" need to pop up without the user activating them first? The usual popups where you click a link or button and a new window is spawned will still work as normal, it's only the unrequested popups that won't work.
Over a dozen of the CSS 3 specifications have reached Candidate Recommendation stage, which means that the W3C ask people to implement them and only major showstoppers can alter them. Mozilla and Apple are already implementing CSS 3 and talking about it, why not Microsoft?
Yep, that's already been pointed out elsewhere in the thread.
According to the bugzilla entry for that bug, the problem is resolved.
Please remember that being marked resolved means that a fix has been checked into CVS. It doesn't mean that it's available in normal builds. In this particular case, it appears that the fix has already made it into a release build, but that's not guaranteed just because it's marked as resolved in Bugzilla.
It seems to me that the Linux UI community has been very busy trying to emulate the functionality of yesterday's commercial desktops, when it should be pioneering new approaches and UI innovations, thus leap-frogging Apple and others.
You have to walk before you can run. The free desktops like KDE and GNOME have incremental improvements over traditional desktops already. For instance, as somebody else mentioned, the "smart folders" concept in the new Mail.app has been present in Evolution for over two years.
Like it or not, the current desktop metaphor is an incredibly apt and productive one. While you are trying to compete with other operating systems, it makes sense to hone the traditional type of interface rather than trying to get people to switch to an entirely unfamiliar interface.
It's not as if more than one project can't work in tandem - work on KDE and GNOME doesn't preclude work on next-generation interfaces like Looking Glass.
Both the whitelist and the install button delay solve this.
Together they do. The whitelist shouldn't be seen as a silver bullet. It shouldn't be possible for somebody who has control over one of the whitelist websites to automatically install something on your computer without your permission.
the install button delay is in Firefox 0.9.1.
My mistake. I took "I landed this patch on the Aviary 1.0 branch" to mean that it would be applied to Firefox 1.0. I can't keep track of the different branches. So Aviary 1.0 stuff goes into Firefox 0.9.1? I'm confused!
I also think that a three second delay is both arbitrary and unsafe. There are plenty of hunt-and-peck typists that would look at the keyboard for three seconds trying to find the 'l' and 'y' keys.
I don't have a better suggestion, except perhaps bringing the confirmation up in a popup that doesn't steal the focus. I don't think a website can trick somebody into switching windows and hitting 'y'.
Slashdot Mirror
This time eight years ago, Linux 2.0 had just been released. The KDE project had only just been started and GNOME wouldn't exist for another year. We were on libc5, just recovering from the changeover from a.out to ELF, and the EGCS fork of GCC hadn't even happened yet, let alone been merged back into the main branch.
I don't think many authors of GPLed works would mind software of that vintage losing GPL protection by entering the public domain.
The Jabber protocol is based around XML, and is in the process of being standardised by the IETF in the XMPP working group. It's also decentralised, so ISPs can offer their own servers and still have people communicate cross-network.
Unfortunately, that means that the existing heavyweights (AOL, Microsoft, etc) lose a hell of a lot of control, so they are unlikely to support it. I'd expect them to compete with each other until it becomes clear that one is going to win, and then the others will throw their weight behind XMPP.
We are talking about the Disability Discrimination Act.
You are right, but it isn't about Odeon "not helping". Websites start out mostly accessible by default. That's how HTML was designed. Odeon went to extra effort to add in code that was entirely aesthetic in nature, that locked out disabled people. If they hadn't taken those extra measures, their site would almost certainly be accessible to disabled people. That's what makes it discrimination and not "not helping". They discarded disabled people for badly-coded Javascript gimmicks.
I completely agree. The standard Python libraries are inconsistent in places, but nowhere near as bad as PHP's. PEAR alleviates this a little, but you might want to check out PiP (Python in PHP). It lets you use objects written in Python from within a PHP script.
You're right, I think that should be an option available through the UI. In the meantime, you can work around it by putting the following in your userChrome.css file and restarting the browser:
tab { font-size: 90%; }Joe-user shouldn't have to install a lot of extensions. What functionality that the "joe-users" use is missing from Firefox?
If a virus can edit the hosts file, it can tamper with HTTPS authentication. There is, however, extra danger from man-in-the-middle attacks and nameserver subversion.
What's sad is that Internet Explorer 6 was released about two and a half years ago, has had no new features added, and they still haven't finished fixing it.
Put the Windows Update site into the "local sites" zone or whatever Internet Explorer calls it. Set the "local sites" security to the same as the Internet zone, and then switch Active Scripting off in the Internet zone.
This effectively emulates the domain-specific Javascript settings in other browsers.
Users can believe whatever they want, it's the browser that pays attention to the whitelist. And if a site can spoof which domain it is coming from, that opens up loads of security holes, not just this one.
That's not true. It's all about managing business risks.
Having software you rely upon fail is a business risk. To make sure that risk doesn't become a problem, "business types" need to look at various factors, such as how likely it is to occur, how disastrous the results could be, and what actions they can take in the event of failure.
The damage that can be done from a security hole is pretty big. So you have to look at how likely it is to occur. Mozilla has show itself to be prone to less security holes than Internet Explorer by quite a wide margin. However, with any reasonably complex software, holes are bound to crop up from time to time, so you can't just say "Mozilla is more secure and that's the end of it".
Instead, you need to look at what kind of action you can take when a security hole is found to mitigate the risk. With Internet Explorer, you have to wait for Microsoft to fix the hole, test the fix, and then deploy it. With Mozilla, the same applies, except you also have the option of fixing it yourself.
Fixing it yourself is almost never the right option. Even if you have in-house developers on staff with experience in the relevent languages (which is very unlikely), they would almost certainly be completely unfamiliar with the Mozilla codebase. The chances of them opening up additional security holes or breaking important functionality when fixing the original security hole is a business risk in itself. So, generally speaking, most businesses will want to wait for the official Mozilla patch.
So you need to look at which organisation is more reliable at getting patches out. Mozilla might be faster, but Microsoft should probably be considered more dependable. After all, they have millions of clients in exactly the same situation as you, and the Mozilla developers can simply walk away from it if it proves too tough to fix.
So, comparing the business risks of using Internet Explorer and Mozilla really depends on which is more important to you - the dependability of being in the same boat as millions of others, or the speed at which Mozilla developers can get a patch out to you. It's got nothing to do with blame.
Why are you asking me? The specification is available to everyone. It says that negative margins are implementation-specific. I'm not sure what you mean by "negative border offsets", it's not normal CSS terminology. Are you talking about padding? The CSS 1 specification explicitly forbids negative padding.
That's not right. The actual string "shell:" is the protocol. Passing off just the protocol part of the URL would be useless. It would be like telling a web browser to go to "http:".
Come off it. All the other major browsers support 99% of the CSS, DOM, etc specifications, so it's unreasonable to criticise Internet Explorer for scraping by with something like 50% support for them?
Nobody advocates authoring to the specifications, using each and every feature, and to hell with the browsers. What people actually advocate is authoring to the specifications, avoiding the troublesome areas that Internet Explorer can't cope with. The 99% support that the other major browsers offer is certainly adequate for that development method.
I thought that was the cause of the recent security hole in Mozilla? That it passed off URLs to be executed as long as the protocol wasn't in a blacklist?
That question was answered years ago. Open-source is used all over the place. Apache is the usual example. Its code has been available for years, it's far more popular than IIS, and yet it's had far less security holes and breakins compared with IIS.
The code's there for you to look at. Feel free to point the backdoors out.
That's because due to Internet Explorer's market share, web developers have no choice but to work around Internet Explorer's bugs or, if that's not possible, give up on certain effects completely. So the thing that makes Internet Explorer more popular is its popularity.
No, making other browsers emulate Internet Explorer is what will drive us towards an Internet Explorer-driven web. What happens when Internet Explorer 6.5 comes out with a new set of behaviours? Other browsers will have to jump to reverse-engineer them and then implement them. And by that time, Internet Explorer 7 will be out, and so the cycle starts again...
Actually, Internet Explorer 6 gets CSS 1 almost completely right. I agree with the "haphazard" description of CSS 2 support though.
Internet Explorer 5.0 was released in March 1999. The CSS 1 specification was published on the 17th of December 1996, and had minor changes, which were published on the 11th of January 1999. Microsoft have employees in the CSS working group that is responsible for these specifications, so they knew about the changes well in advance of the rest of the world.
Let's not forget the five year old HTTP 1.1 and the eight year old PNG specifications that they still haven't implemented correctly. But it's not as if Microsoft have loads of resources to spare, is it? I mean, they are hardly the world's biggest software company!
I think you may be misinterpreting what Jezral is getting at.
Filename extensions have never been part of the WWW. Sure, you get URLs with dots in various places, but that doesn't mean anything. At least not in browsers that adhere to the specifications.
The HTTP specification, RFC 2616, explicitly states that web browsers may not attempt to guess a file type when a Content-Type header has been provided. Internet Explorer does, paying attention to what comes after dots in a URL and the first few bytes of a resource. That is flat-out incorrect behaviour.
The Content-Type header is more flexible and standardised than a random three letter extension on the end of a URL, and much easier to disambiguate by clients.
Microsoft seem to be fixing this issue a little with the service pack update, but to what extent is unknown - so far as their description of the behaviour is a little confusing.
Wanting this issue to be addressed by Microsoft is not the same as wanting to remove your file extensions from your OS.
Which "valid popups" need to pop up without the user activating them first? The usual popups where you click a link or button and a new window is spawned will still work as normal, it's only the unrequested popups that won't work.
Over a dozen of the CSS 3 specifications have reached Candidate Recommendation stage, which means that the W3C ask people to implement them and only major showstoppers can alter them. Mozilla and Apple are already implementing CSS 3 and talking about it, why not Microsoft?
Yep, that's already been pointed out elsewhere in the thread.
Please remember that being marked resolved means that a fix has been checked into CVS. It doesn't mean that it's available in normal builds. In this particular case, it appears that the fix has already made it into a release build, but that's not guaranteed just because it's marked as resolved in Bugzilla.
You mean things like Looking Glass and Metisse?
You have to walk before you can run. The free desktops like KDE and GNOME have incremental improvements over traditional desktops already. For instance, as somebody else mentioned, the "smart folders" concept in the new Mail.app has been present in Evolution for over two years.
Like it or not, the current desktop metaphor is an incredibly apt and productive one. While you are trying to compete with other operating systems, it makes sense to hone the traditional type of interface rather than trying to get people to switch to an entirely unfamiliar interface.
It's not as if more than one project can't work in tandem - work on KDE and GNOME doesn't preclude work on next-generation interfaces like Looking Glass.
Together they do. The whitelist shouldn't be seen as a silver bullet. It shouldn't be possible for somebody who has control over one of the whitelist websites to automatically install something on your computer without your permission.
My mistake. I took "I landed this patch on the Aviary 1.0 branch" to mean that it would be applied to Firefox 1.0. I can't keep track of the different branches. So Aviary 1.0 stuff goes into Firefox 0.9.1? I'm confused!
I also think that a three second delay is both arbitrary and unsafe. There are plenty of hunt-and-peck typists that would look at the keyboard for three seconds trying to find the 'l' and 'y' keys.
I don't have a better suggestion, except perhaps bringing the confirmation up in a popup that doesn't steal the focus. I don't think a website can trick somebody into switching windows and hitting 'y'.
Are you sure about that? That security hole won't be fixed until Firefox 1.0.