The problem with using << for C++ I/O streams isn't really the use of operator overloading, it's the fact that it puts into code what should be data: the order of the terms to be output. As anyone who's worked with internationalised code much can tell you, that's a "D'oh!" mistake.
As for readability, I write serious maths software using C++. We already use complex matrix multiplication expressions and the like, which are hard enough to read already when you're constrained to a textual representation. From a numerical programmer's perspective, you can have my overloaded (and highly readable) operators over my code, dead body.
Developer productivity, in terms of finished lines of code produced per day, is remarkably consistent across programming languages. If you insist that a trivial expression be written as five lines of crap, you just reduced your developer productivity to 20% of what it was. (Before anybody flames, please read the research. Google is your friend.)
Replacing a simple and transparent expression with five lines of crap makes the code vastly harder to read. There is far more scope for introducing no-brainer bugs, and it will be far harder for anyone reviewing the code to identify and remove them.
In many languages, using a consistent syntax to represent the same logical operations allows you to write generic code that can work on all types supporting that syntax. In most parts of the programming world, we call addition "+" and multiplication "*". Pointless diversity just hinders code reuse in one of the few areas where it actually is more than just a buzzphrase.
We use high level languages instead of assembler because they let us work at varying levels of abstraction, keeping what we're doing relatively simple at each level and delegating the details to the levels below. That makes for more readable, less error-prone code. What you're advocating is the very antithesis of this approach; if you're going to be that clumsy, you might as well write in assembler. In fact, on reflection, that would be neater...
Putting code in comments is a bad idea, because comments can't be verified. A misleading comment does more harm than good: it takes extra time for a developer unfamiliar with the code to work out what it does, and to realise that the comment is incorrect. This is the most important reason to write "self-documenting" code, i.e., code that describes its own behaviour without the need to duplicate that work in a comment (as the great-great-...-grandparent post so hideously suggested).
Comments, like any other documentation, are beneficial in that they can describe in abstract terms what the code is doing -- the "big picture", if you like -- where sometimes it's not convenient to do that with the code itself.
Comments specifically are also useful if a line of code necessarily looks like it's doing something unusual, although I would always prefer rewriting such a line to be clear in its intent if it's practical to do so.
The point is that these uses complement the code itself. They don't duplicate it, which is just a waste of time and a potential source of errors for no apparent benefit.
If you find yourself doing MI where the same base class gets inherited there's a very good chance you're doing something wrong.
There are schools of thought that would argue any use of MI that doesn't involve common base classes is probably doing something wrong. In practice, either view is rather absolute, no?
There are useful idioms using mix-ins, and there are times when combining two separate hierarchies is justified. There aren't many of either -- hence the unpopularity of any sort of multiple inheritance of implementation in some quarters -- but IME both have their uses, and when the time is right, it's much simpler to use the appropriate MI-based design than to work around it.
Slapping an ASBO on the execs is a fascinating approach that hadn't even occurred to me until you mentioned it. Do you have a reference to the cases in question, please? It sounds like quite a brilliantly simple solution to the problem to me...
As an aside, treating the takedown notice to an ISP as defamatory was mentioned later in this discussion, and also sounds like a straightforward approach.
Bottom line: we have existing laws to counter intimidation, anti-social behaviour and defamation. Why do we need something whizzy and special in this case? Of course, we have existing laws to counter monopoly abuse and price-fixing, too, and look where those have got us.;-)
Could this be another case of US copyright laws being enforced in another country?
That seems unlikely. As much as the MPAA might wish it otherwise, US copyright law applies to the US, and somewhere else's copyright law applies somewhere else. I don't imagine it will take a genius lawyer to advise their client to tell the MPAA to go screw themselves where there's no equivalent local law...
Most of the security bugs affecting OS programs seem to be buffer overflows or input parsing problems.
Most of the detected security bugs in any program are trivia like buffer over-runs and straightforward SQL injection attacks. Unfortunately, there are plenty of other possibilities; the fact that they often haven't been identified in OSS doesn't mean they aren't there. In fact, didn't TFA mention this issue?
In a well-intentioned attempt to block a potential security issue, Moz/Firefox don't allow the use of the file: protocol by default. Unfortunately, this obviously hampers numerous legitimate uses where intranets are concerned. There has been a bug in Bugzilla on this for something like three years now, with dozens of supporting comments, loads of dupes and dozens of votes, but still the "feature" remains. There is a switch in about:config that allegedly lets you disable the check so file: works, but IME it still doesn't work properly even with that adjustment.
This rather glaring problem was the reason for my admittedly rather sarcastic comment about SP2 disabling Javascript and thus disrupting many legitimate applications; from the above, it's clear that OSS can suffer from similar "lapses in concentration" just as easily.
I'm certainly not saying this sort of thing can't be done on Linux. Without the Curse Of The Registry(TM), simple copying of files by some automated means can obviously achieve a lot alone, and of course there are always tools that go some way beyond that. My concern was more that there comes a point where something is too complicated for the simple approach and tools are all you've got, and you can achieve much more with the tools you get with a serious Windows-based network, at least for now.
You're confusing shell: and file: (although your arguments would be wrong even if we were talking about shell:). Please go back to page 1 and start again.:-)
The statement "In the land of the blind, the one eyed man will be king" simply means that closed source developers (one eye man) want to discredit OSS (millions of open eyes) because it keeps them in wealth and keeps them in control (king)...
Damn. I was just going to mod you up, assuming you meant that one guy who actually knows about security is worth more as a code reviewer than a legion of OSS geeks who don't.
Your example is rather misleading, even if unintentionally.
The highly publicised shell: vulnerability in that specific bug may have only been reported shortly before the fix was issued. The architectural flaw was apparently identified way, way earlier, but it was decided not to act on it at the time.
In fact, this is probably the example I would cite to demonstrate OSS failing to address known vulnerabilities in a timely fashion. It's particularly worrying because it wasn't some trivial buffer over-run, it was a fundamental architectural weakness. The dev team knew that, but made the erroneous judgement that it didn't matter. IE had seen this one coming and fixed it months earlier, BTW.
... once something is actually found, it's fixed a lot faster than in most commercial software.
Damn, we've got all the old half-truths out today, haven't we?
Ladies and gentlemen of the geek world, Microsoft != All Commercial Software.
Many commercial developers, up to and including those who ship major operating systems and the like, provide an excellent turnaround time on serious bugs. I work for one, and my boss just spent today getting a critical bug fix out to a client within 24 hours, something that isn't at all unusual for the guys working on maintenance there. That's a fully regression-tested bug fix in a large component with more than a decade of development behind it, by the way. For a more mainstream example, look at the speed Apple typically fixes security issues in MacOS X.
And of course, there are numerous examples of long-running and much-loathed bugs being left outstanding for months or even years in OSS, even in major projects like Mozilla and OpenOffice.
This whole "OSS fixes it faster" mantra is getting very tired now, as are all the other standard sound-bites ("More secure!", "Future-proof!"). Until these discussions start getting some perspective, and certain parts of the OSS world start acknowledging that their methodology does not have some God-given right to be perfect, how are we ever going to address the problems that do exist?
The main point with Open Source is that the source is, umm... open. Hence the market for M&S is similarly open (and competitive), and you are free to decide whether to handle it internally or externally as you see fit.
This is one of those OSS myths, like the security one discussed here the other day. The fact that a large project's source is open doesn't even slightly mean that just anyone can come along to develop new features or bug fixes. The barrier to entry involved in learning a large project is huge even if it's well-documented and impeccably designed. Without the original dev team around, you're basically sunk. If there is an exception to this rule, I've never seen it, either in OSS or commercial development land.
One day, my boss will choke on his "we should just design for Microsoft IE and if it doesn't work in your Mozilla then maybe you shouldn't use it." Bastard.
My managers have been quite happy for me to use Firefox. However, since Firefox still doesn't get the file: protocol, and the widely-quoted fix still doesn't seem to work, it's still screwed on just about any intranet in the universe. So, now I'm going to be officially forced to go back to IE at work, because we've just set up a serious intranet, too.:-(
This has been one of the most-duped bugs in the history of Mozilla (it goes back to way before FF's time). It has numerous votes, and should be straightforward to fix, but hasn't been because of a (dubious) security concern. Not exactly the finest example of OSS fixing important problems quickly and being better than the CSS alternatives!
In my opinion as a one-time Perl6/Parrot devotee, it's taken too long. By the time it ships, it'll be irrelevant.
This is known technically as "C++ syndrome".:-)
On the other hand, I don't see many dramatic advances in the other popular scripting languages either. I've picked up quite a bit of Perl over the past few years -- some of us do use it for reporting:-) -- and I've taken a look at both Python and Ruby on several occasions during that time, too. Every time, my underwhelmed reaction was: "Wow, another scripting language, but what does it offer that I don't already have?"
That's not to say that the alternatives aren't good, or that some people won't prefer them. Personally, I prefer languages to restrict punctuation to enhancing readability and keep the cryptic shorthand to specific cases like regexes or string formatting. IOWs, I'm a natural fan of things like Python and functional programming languages, and I think Perl tends to go too far. Other people go for OO in a big way, so they're likely to prefer Ruby. But I guess my answer to this...
Why should I use Perl6 instead of Python/PHP?
...is "Why shouldn't you?" Nothing else has yet developed far enough beyond Perl to merit conversion if you already know the latter, so why switch "just because"?
Maybe if they would have had it done a year or two ago it would have still been able to generate some buzz, but now it would appear that the people who wanted major improvements to the language (especially OO features) have moved on to other languages like Ruby.
That's kind of an odd example, because "everything is an object" is only an approximation, and IME it's only a good enough approximation to offer any benefits in medium-large developments. We're talking about languages principally used for scripting purposes here, a different world entirely.
I hope Perl isn't going to try and turn into a large-scale, OO-crazy development language. We've already got several of those, and all them are much more suited to the task than Perl.
Well, one underlying technology is Active Directory. As others have noted in the various Mozilla-related threads over the past couple of days, if there were an MSI for Firefox available, this could be used to deploy it remotely to a particular part of an Active Directory based network, for example. Windows Update is another part of the picture. From Windows 2000 onwards, a lot of these technologies interact fairly well.
As far as I'm aware, no major Linux distribution currently supports anything close to the same level of centralised configuration, so you'd need users to apt-get (or whatever) updates themselves on each machine rather than deploying a patch everywhere automatically via the IT guys.
Ob. disclaimer: I'm no expert on large network administration in either Windows or Linux. If you need to know any of this stuff seriously, I am not the guy to ask.
In other words, and to get back on track, what's missing from Firefox etc. at the moment isn't just an automatic update facility, but from a corporate point of view it's a centrally manageable automatic update facility.
Thanks, but don't be. Windows and its apps are demonstrably capable of supporting large organisations' networks and remote administration in a way that Linux fans only have wet dreams about right now. You're allowed to bitch about corporate security risks when your alternative can do the basic job at all, and not before.
Do you really think all the smart, well-trained and well-funded senior sysadmins at large organisations are sticking with Windows because they've never heard of or evaluated the alternatives? Do you really think they wouldn't shift to an alternative standard that would fix most of their security worries if they didn't see any downside? Of course not. (Admittedly, there are a significant number who do go for "Nobody ever got fired for buying Microsoft" as well.)
The harsh reality is that even if the compatibility worries are overcome, without the centralised administration tools, Linux is dead on the business desktop. The exception will be companies where the average staffer is sufficiently technical to take advantage of it, which mostly means the smaller techie outfits and not much else. That's why OSS is popular in the (admin-controlled) server market, but rarely seen on (luser-controlled) corporate desktops.
This is changing, of course. More of those smart sysadmins are actively researching alternatives to Microsoft's offerings, which will provide momentum, and possibly even funding to bridge the gaps. With a decent business-wide remote admin/roll-out system, a combination like Linux+Moz apps+OpenOffice apps could become a serious player. But today it's not, so while we Windoze lusers appreciate your sympathy, you'd best keep it for now.
Or run them side by side to see if they act properly and as expected.
I'm not sure what that was aimed at, but from direct personal experience, Mozilla and Firefox do not play nicely on the same machine. I've been waiting for the Thunderbird release that can import Moz mail before upgrading, but using Firefox as my browser for some time. Simple things like opening mailto: links or following a link in an HTML e-mail don't open the right tool, and they're constantly fighting over who's going to be my default tool for what. I'm looking forward to nuking this system and installing clean, including the new versions of Firefox and Thunderbird, later this month.
Technically that was a Windows problem, Mozilla just handed the URL off to Windows because it didn't have a handler registered for it.
Yes. The fact remains that Mozilla had a known exploitable architectural flaw -- which is far more serious than your average careless bug -- for several months, and the developers decided not to act on it. (IE was immune to that "Windows" vulnerability a long time ago, BTW.)
Firefox has an automated update checker builtin, I havn't used it so I can't vouch for it though.
No automatic update facility in any version of Moz or its derivatives has ever worked for me, and I've been using them since something like Moz 1.1 now. A lot of people on this thread seem to think the 1.0 release of Firefox will support this properly; let's hope so!
That's because it's still a beta
Sure, and so is half of what MS ships, but that doesn't change the fact that many geeks are encouraging people to switch from IE to FF (beta or otherwise), when the latter isn't yet up to speed on basics like automatic security updates.
As always, the people I'm criticising here are not the Moz/FF devs, but those who advocate Average Joe switching to a product that isn't finished yet without considering how non-geeks use computers.
Overheads have always been expensive. Frankly, I'm amazed it's less than 100% of salary; here in the UK, contractors typically charge out at a rate 2.5x the equivalent salary position as a minimum, which is regarded as a reasonable rate given the overheads they have to pick up as non-employees.
The fact remains that two semi-productive employees with all the incumbent overheads are still more useful than one actively counter-productive employee doing a 70+ hour week.
Mozilla's security updates do not have a history of breaking things.
That is a matter of opinion. I haven't upgraded Moz on my home machine since the 1.5->1.6 switch took out my whole e-mail store, address book, and other profile information. Fortunately I'd had the sense to back up, so 1.5 was restored with the only loss several hours of my time. It does make the argument that Mozilla doesn't have to provide security patches for older versions because of the rapid upgrade cycle rather thin, though.
I've been waiting for TBird to import Moz e-mail properly, and now that it does, I'll be shifting away from the Mozilla suite to Firefox and Thunderbird imminently. The latter seem to be far more robust than Mozilla itself, which sadly has become ever more feature-loaded and bug-ridden with the passage of time.
Slashdot Mirror
The problem with using << for C++ I/O streams isn't really the use of operator overloading, it's the fact that it puts into code what should be data: the order of the terms to be output. As anyone who's worked with internationalised code much can tell you, that's a "D'oh!" mistake.
As for readability, I write serious maths software using C++. We already use complex matrix multiplication expressions and the like, which are hard enough to read already when you're constrained to a textual representation. From a numerical programmer's perspective, you can have my overloaded (and highly readable) operators over my code, dead body.
Here are a few reasons not to do it.
We use high level languages instead of assembler because they let us work at varying levels of abstraction, keeping what we're doing relatively simple at each level and delegating the details to the levels below. That makes for more readable, less error-prone code. What you're advocating is the very antithesis of this approach; if you're going to be that clumsy, you might as well write in assembler. In fact, on reflection, that would be neater...
I'll back it up for him...
Putting code in comments is a bad idea, because comments can't be verified. A misleading comment does more harm than good: it takes extra time for a developer unfamiliar with the code to work out what it does, and to realise that the comment is incorrect. This is the most important reason to write "self-documenting" code, i.e., code that describes its own behaviour without the need to duplicate that work in a comment (as the great-great-...-grandparent post so hideously suggested).
Comments, like any other documentation, are beneficial in that they can describe in abstract terms what the code is doing -- the "big picture", if you like -- where sometimes it's not convenient to do that with the code itself.
Comments specifically are also useful if a line of code necessarily looks like it's doing something unusual, although I would always prefer rewriting such a line to be clear in its intent if it's practical to do so.
The point is that these uses complement the code itself. They don't duplicate it, which is just a waste of time and a potential source of errors for no apparent benefit.
There are schools of thought that would argue any use of MI that doesn't involve common base classes is probably doing something wrong. In practice, either view is rather absolute, no?
There are useful idioms using mix-ins, and there are times when combining two separate hierarchies is justified. There aren't many of either -- hence the unpopularity of any sort of multiple inheritance of implementation in some quarters -- but IME both have their uses, and when the time is right, it's much simpler to use the appropriate MI-based design than to work around it.
Slapping an ASBO on the execs is a fascinating approach that hadn't even occurred to me until you mentioned it. Do you have a reference to the cases in question, please? It sounds like quite a brilliantly simple solution to the problem to me...
As an aside, treating the takedown notice to an ISP as defamatory was mentioned later in this discussion, and also sounds like a straightforward approach.
Bottom line: we have existing laws to counter intimidation, anti-social behaviour and defamation. Why do we need something whizzy and special in this case? Of course, we have existing laws to counter monopoly abuse and price-fixing, too, and look where those have got us. ;-)
That seems unlikely. As much as the MPAA might wish it otherwise, US copyright law applies to the US, and somewhere else's copyright law applies somewhere else. I don't imagine it will take a genius lawyer to advise their client to tell the MPAA to go screw themselves where there's no equivalent local law...
And mayhap the use of the apostrophe as well?
Sorry, couldn't resist. Hoping I'm not about to submit an embarrassing typo now... :-)
Most of the detected security bugs in any program are trivia like buffer over-runs and straightforward SQL injection attacks. Unfortunately, there are plenty of other possibilities; the fact that they often haven't been identified in OSS doesn't mean they aren't there. In fact, didn't TFA mention this issue?
In a well-intentioned attempt to block a potential security issue, Moz/Firefox don't allow the use of the file: protocol by default. Unfortunately, this obviously hampers numerous legitimate uses where intranets are concerned. There has been a bug in Bugzilla on this for something like three years now, with dozens of supporting comments, loads of dupes and dozens of votes, but still the "feature" remains. There is a switch in about:config that allegedly lets you disable the check so file: works, but IME it still doesn't work properly even with that adjustment.
This rather glaring problem was the reason for my admittedly rather sarcastic comment about SP2 disabling Javascript and thus disrupting many legitimate applications; from the above, it's clear that OSS can suffer from similar "lapses in concentration" just as easily.
I'm certainly not saying this sort of thing can't be done on Linux. Without the Curse Of The Registry(TM), simple copying of files by some automated means can obviously achieve a lot alone, and of course there are always tools that go some way beyond that. My concern was more that there comes a point where something is too complicated for the simple approach and tools are all you've got, and you can achieve much more with the tools you get with a serious Windows-based network, at least for now.
You're confusing shell: and file: (although your arguments would be wrong even if we were talking about shell:). Please go back to page 1 and start again. :-)
Damn. I was just going to mod you up, assuming you meant that one guy who actually knows about security is worth more as a code reviewer than a legion of OSS geeks who don't.
Your example is rather misleading, even if unintentionally.
The highly publicised shell: vulnerability in that specific bug may have only been reported shortly before the fix was issued. The architectural flaw was apparently identified way, way earlier, but it was decided not to act on it at the time.
In fact, this is probably the example I would cite to demonstrate OSS failing to address known vulnerabilities in a timely fashion. It's particularly worrying because it wasn't some trivial buffer over-run, it was a fundamental architectural weakness. The dev team knew that, but made the erroneous judgement that it didn't matter. IE had seen this one coming and fixed it months earlier, BTW.
Nasty cough you've got there. I think I caught the same thing when I was talking about Firefox and the file: protocol yesterday.
Damn, we've got all the old half-truths out today, haven't we?
Ladies and gentlemen of the geek world, Microsoft != All Commercial Software.
Many commercial developers, up to and including those who ship major operating systems and the like, provide an excellent turnaround time on serious bugs. I work for one, and my boss just spent today getting a critical bug fix out to a client within 24 hours, something that isn't at all unusual for the guys working on maintenance there. That's a fully regression-tested bug fix in a large component with more than a decade of development behind it, by the way. For a more mainstream example, look at the speed Apple typically fixes security issues in MacOS X.
And of course, there are numerous examples of long-running and much-loathed bugs being left outstanding for months or even years in OSS, even in major projects like Mozilla and OpenOffice.
This whole "OSS fixes it faster" mantra is getting very tired now, as are all the other standard sound-bites ("More secure!", "Future-proof!"). Until these discussions start getting some perspective, and certain parts of the OSS world start acknowledging that their methodology does not have some God-given right to be perfect, how are we ever going to address the problems that do exist?
This is one of those OSS myths, like the security one discussed here the other day. The fact that a large project's source is open doesn't even slightly mean that just anyone can come along to develop new features or bug fixes. The barrier to entry involved in learning a large project is huge even if it's well-documented and impeccably designed. Without the original dev team around, you're basically sunk. If there is an exception to this rule, I've never seen it, either in OSS or commercial development land.
My managers have been quite happy for me to use Firefox. However, since Firefox still doesn't get the file: protocol, and the widely-quoted fix still doesn't seem to work, it's still screwed on just about any intranet in the universe. So, now I'm going to be officially forced to go back to IE at work, because we've just set up a serious intranet, too. :-(
This has been one of the most-duped bugs in the history of Mozilla (it goes back to way before FF's time). It has numerous votes, and should be straightforward to fix, but hasn't been because of a (dubious) security concern. Not exactly the finest example of OSS fixing important problems quickly and being better than the CSS alternatives!
This is known technically as "C++ syndrome". :-)
On the other hand, I don't see many dramatic advances in the other popular scripting languages either. I've picked up quite a bit of Perl over the past few years -- some of us do use it for reporting :-) -- and I've taken a look at both Python and Ruby on several occasions during that time, too. Every time, my underwhelmed reaction was: "Wow, another scripting language, but what does it offer that I don't already have?"
That's not to say that the alternatives aren't good, or that some people won't prefer them. Personally, I prefer languages to restrict punctuation to enhancing readability and keep the cryptic shorthand to specific cases like regexes or string formatting. IOWs, I'm a natural fan of things like Python and functional programming languages, and I think Perl tends to go too far. Other people go for OO in a big way, so they're likely to prefer Ruby. But I guess my answer to this...
...is "Why shouldn't you?" Nothing else has yet developed far enough beyond Perl to merit conversion if you already know the latter, so why switch "just because"?
That's kind of an odd example, because "everything is an object" is only an approximation, and IME it's only a good enough approximation to offer any benefits in medium-large developments. We're talking about languages principally used for scripting purposes here, a different world entirely.
I hope Perl isn't going to try and turn into a large-scale, OO-crazy development language. We've already got several of those, and all them are much more suited to the task than Perl.
Well, one underlying technology is Active Directory. As others have noted in the various Mozilla-related threads over the past couple of days, if there were an MSI for Firefox available, this could be used to deploy it remotely to a particular part of an Active Directory based network, for example. Windows Update is another part of the picture. From Windows 2000 onwards, a lot of these technologies interact fairly well.
If you're not familiar with the scope of Active Directory, you might like to read an introductory article from Microsoft on the subject.
As far as I'm aware, no major Linux distribution currently supports anything close to the same level of centralised configuration, so you'd need users to apt-get (or whatever) updates themselves on each machine rather than deploying a patch everywhere automatically via the IT guys.
Ob. disclaimer: I'm no expert on large network administration in either Windows or Linux. If you need to know any of this stuff seriously, I am not the guy to ask.
In other words, and to get back on track, what's missing from Firefox etc. at the moment isn't just an automatic update facility, but from a corporate point of view it's a centrally manageable automatic update facility.
Thanks, but don't be. Windows and its apps are demonstrably capable of supporting large organisations' networks and remote administration in a way that Linux fans only have wet dreams about right now. You're allowed to bitch about corporate security risks when your alternative can do the basic job at all, and not before.
Do you really think all the smart, well-trained and well-funded senior sysadmins at large organisations are sticking with Windows because they've never heard of or evaluated the alternatives? Do you really think they wouldn't shift to an alternative standard that would fix most of their security worries if they didn't see any downside? Of course not. (Admittedly, there are a significant number who do go for "Nobody ever got fired for buying Microsoft" as well.)
The harsh reality is that even if the compatibility worries are overcome, without the centralised administration tools, Linux is dead on the business desktop. The exception will be companies where the average staffer is sufficiently technical to take advantage of it, which mostly means the smaller techie outfits and not much else. That's why OSS is popular in the (admin-controlled) server market, but rarely seen on (luser-controlled) corporate desktops.
This is changing, of course. More of those smart sysadmins are actively researching alternatives to Microsoft's offerings, which will provide momentum, and possibly even funding to bridge the gaps. With a decent business-wide remote admin/roll-out system, a combination like Linux+Moz apps+OpenOffice apps could become a serious player. But today it's not, so while we Windoze lusers appreciate your sympathy, you'd best keep it for now.
I'm not sure what that was aimed at, but from direct personal experience, Mozilla and Firefox do not play nicely on the same machine. I've been waiting for the Thunderbird release that can import Moz mail before upgrading, but using Firefox as my browser for some time. Simple things like opening mailto: links or following a link in an HTML e-mail don't open the right tool, and they're constantly fighting over who's going to be my default tool for what. I'm looking forward to nuking this system and installing clean, including the new versions of Firefox and Thunderbird, later this month.
Yes. The fact remains that Mozilla had a known exploitable architectural flaw -- which is far more serious than your average careless bug -- for several months, and the developers decided not to act on it. (IE was immune to that "Windows" vulnerability a long time ago, BTW.)
No automatic update facility in any version of Moz or its derivatives has ever worked for me, and I've been using them since something like Moz 1.1 now. A lot of people on this thread seem to think the 1.0 release of Firefox will support this properly; let's hope so!
Sure, and so is half of what MS ships, but that doesn't change the fact that many geeks are encouraging people to switch from IE to FF (beta or otherwise), when the latter isn't yet up to speed on basics like automatic security updates.
As always, the people I'm criticising here are not the Moz/FF devs, but those who advocate Average Joe switching to a product that isn't finished yet without considering how non-geeks use computers.
Overheads have always been expensive. Frankly, I'm amazed it's less than 100% of salary; here in the UK, contractors typically charge out at a rate 2.5x the equivalent salary position as a minimum, which is regarded as a reasonable rate given the overheads they have to pick up as non-employees.
The fact remains that two semi-productive employees with all the incumbent overheads are still more useful than one actively counter-productive employee doing a 70+ hour week.
That is a matter of opinion. I haven't upgraded Moz on my home machine since the 1.5->1.6 switch took out my whole e-mail store, address book, and other profile information. Fortunately I'd had the sense to back up, so 1.5 was restored with the only loss several hours of my time. It does make the argument that Mozilla doesn't have to provide security patches for older versions because of the rapid upgrade cycle rather thin, though.
I've been waiting for TBird to import Moz e-mail properly, and now that it does, I'll be shifting away from the Mozilla suite to Firefox and Thunderbird imminently. The latter seem to be far more robust than Mozilla itself, which sadly has become ever more feature-loaded and bug-ridden with the passage of time.