I wouldn't really regard it as the case that old versions are not supported; its a simple statement that you should use the latest stable milestone, which fixes all major issues known at that stage. [...] However, I'm sure you've noticed Windows Update still gives you an IE related patch as often, if not more, than Moz gives you a formal update...
That's true, of course, but the point here is that Windows Update does give them to me for IE. Even if I'm not using the most up-to-date version, I still get patches for critical vulnerabilities, and they still get sent to my notifications tray automatically if Windows Update is on.
My objection here is that, as a Mozilla 1.5 user, I couldn't find any information on whether this vulnerability affected me (aside from a one-liner I eventually found deep within Mozilla's site that said "versions up to 1.7") or any information at all on what I needed to do to fix it in 1.5. As a programmer, I can extrapolate from the descriptions I have seen, but none of this would help Joe Family-Member who I'd convinced to switch to Moz when 1.5 was current.
Should emphasise at this point I'm not truly anti IE, but I can't live without tabbed browsing, popup blocking, a less vulnerable email client......:-)
I like them too; that's why I use Mozilla. And for the avoidance of doubt, I think the dev team on the whole do a great job, and I'm grateful for their efforts. I've just seen them drop the ball in a Very Bad Way twice too often now -- once to stop me upgrading, and again in apparently not supporting the "old" version -- and I'm starting to get worried. As a geek, I can understand that, and tolerate it. It's just a shame for the mainstream, because it reduces what should be a superior solution to the level of IE/Outlook.
I did back everything up, which was fortunate since I needed to restore from that backup immediately.
However, my faith in the system is now shaken beyond repair. Upgrade instructions for Mozilla versions have always been pretty useless, and a screw up that spectacular in a straightforward upgrade betrays underlying weaknesses that are scary in any application that I'm going to depend on.
The more scary thing, however, is that the attitude appears to be that "old" versions are not supported. That's a very "open source, update from the CVS tree every night" attitude, but has no place in the real world. Given that this is software with an age best measured in months, that's a fairly serious flaw as far as making it into the mainstream -- most people aren't going to upgrade their Mozilla versions regularly, if at all.
No, I'll wait for Thunderbird/Firefox to hit 1.0 and then move, but I won't upgrade Mozilla again. In the meantime, I'll have to try and work out how to patch this up in 1.5, and if anything serious happens, I'll go back to IE.
I totally agree about functional languages and monads. They're theoretically elegant solution to a major practical problem, but always seem far too awkward in actual use (though I'm no expert on this subject).
What I'd like to see is the reverse approach: an imperative language that supports higher-order functions, currying, etc. properly. I don't see any problem with this approach, yet the most (only?) serious attempt to bridge the imperative/functional gap so far seems to be OCaml, which starts from a functional approach and adds imperative-like features (and, IMHO, not particularly cleanly). One need only look at the flexibility evident in scripting languages that provide basic support for functional programming concepts to see the potential.
[C++] generics are child's toys compared to those in other languages;
I'm not sure what you mean -could you give an example? C++ templates do the functional-style polymorphism quite well, i.e. an operation can be applied to an arbitrary type (or sequence thereof usually).
That's true, of course, up to a point. They're certainly very useful things. The problem is they're so awkward, both to write and to use. Compare something like this fairly typical C++ style:
template <<typename Cont, typename T> bool contains(Cont c, T x) { for (Cont::iterator it = c.begin(); it != c.end(); ++it) { if (*it == x) return true; } return false; }
with this fairly typical ML style (neglecting the fact that you'd probably do this with a higher-order function in such a language anyway):
fun contains (x, []) = false | (x, h::t) = h = t orelse contains (x, t);
The combination of type inference, implicit genericity, and pattern matching in the functional version makes for much more concise code.
Additionally you have the immense metaprogramming power right there for you to tap into including compile-time polymorphism (the OO kind) and other nifty stuff.
That's true, if inadvertent. However, at the risk of using an old cliche, look at LISP if you want to see what metaprogramming can really do.
Finally, regarding Ruby blocks, what does that approach offer over a fairly common idiom (in random pseudo-code):
foreach element in array_of_elements: do_something_with element
or the obvious functional version:
apply do_something_with array_of_elements
The technique is useful, but I don't see why Ruby's blocks offer anything new or different. Am I missing something here?
This is certainly true to a point. There are three basic kinds of data used throughout the programming world: text, numbers and logic (true/false). Pretty much any mainstream general-purpose language provides basic arithmetic and logical operators, and then an extensive library of more advanced mathematics functions. With strings, you often get basic operators, but beyond those there's a world of difference between providing a couple of upper-/lower-case conversions and having things like regular expressions supplied as standard.
I think part of this problem is that what constitutes good support for strings isn't nearly as clear-cut as it is with numbers. Should we provide mutable and non-mutable types? How much should the regexes support? How do we deal with international issues?
The latter is a biggie that I think will become more significant as time goes on and markets expand worldwide. Frankly, most languages suck when it comes to dealing with translating text and working with foreign languages. Consider how many provide a function mapping a character onto its upper-case equivalent; what it's supposed to do with a German double-s? Some languages get text support spectacularly wrong: C++'s much heralded IOStreams system codifies structure that should be data, and thus makes itself almost completely useless for any sort of internationalised development; all the locales in the world won't change the fact that different languages use different word order conventions.
I think the underlying problem here is that text is fundamentally a complicated thing. Numbers, whether integers, fixed- or floating-point, have fairly well-defined rules (though as any numerical analyst will tell you, they don't necessarily match those of mathematics). Text, however, is on a different level. Even dealing with simple concepts like a case-insensitive comparison (assuming your input language even has cases in this sense) can be hugely complicated in practice, and complications like multiple word-forms multiply up to make it many times more difficult than typical mathematical code. It's more like expecting calculus to be built into a simple programming language, except that relatively few apps need that level of maths, while just about anything with a UI potentially needs that level of text support.
Even if you're only dealing with manipulations of well-structured text in a single language, not all processing fits neatly into the idioms offered by regular expressions. Regexes are powerful tools, to be sure, but I think we're still waiting for the not-quite-silver bullet in text processing to arrive. I expect this to be something based on higher level concepts than a simple list of characters, possibly to be very demanding of processing power (though viable with tomorrow's technology), and probably to revolutionise the international development community like nothing we've ever seen before.
So yes, I agree completely, good text processing is a very important feature for a programming language. If only any of them had it...;-)
C allows you to return functions if you so desire.
Well, it allows you to return function pointers, which certainly have their uses. However, your program has eight non-trivial lines of code, but would be written in around three lines in just about any language supporting serious functional idioms, something like this (in random functional pseudo-code):
fun main = returnfunc fun returnfunc = returnme fun returnme = print "I tawt I taw a puddy cat\n"
Such features, having much simpler syntax, would also be immune to the error involving pointer notation that you made. Moreover, a compiler that understands functions to this level would almost certainly reduce this to main being the print expression, which no C optimiser is likely to do in your case.
Your simple example is a perfect demonstration of exactly why C sucks in this particular respect.
I'll go with the lambda function bit, but I'm not entirely convinced by the rest.:-)
I rather unsubtly advocate C++ around these parts from time to time, but that's because I think it's incredibly well-engineered for a real-world tool. It has a lot of "powerful enough" features, and you can get work done with it. However, if we're talking about favourite features for a language, presumably we're going for ideals, in which case frankly C++ sucks on most counts: its OO features can be cumbersome to use; its generics are child's toys compared to those in other languages; its syntax generally is terrible; and it's missing any serious support for functional idioms.
Ruby blocks are, as far as I can tell, just a rather unusual syntax for fairly routine concepts. Quite a few people seem to like them, so I assume they do their job well in the context of Ruby as a whole, but what's special about them that a dozen other languages can't do in their own way?
Lazy evaluation is an intriguing concept, but suffers from the classic flaw of many purely functional languages: in realistic problems, things don't run on abstract machines in isolated worlds, and a certain level of determinism is required to get things done. I've yet to see a really compelling example of code that is particularly elegant or efficient using lazy evaluation, but can't be written similarly elegantly and efficiently using some sort of generator/iterator idiom and perhaps a basic optimiser.
Lambda functions, and in fact the whole family of related concepts -- higher-order functions, currying, anonymous functions, closures -- just make life so much easier. Working in languages that provide at least modest support for these ideas (in the sense of, say, Perl rather than ML or Haskell) always seems less like hard work than using something like C++, where the closest you get is some template wizardry which, looked at objectively, is pretty much off the scale at the wrong end. Functional idioms rock, and why no-one has yet produced a solid imperative language that integrates these features cleanly and comprehensively I do not know...
We use graphical interfaces for a lot of things, we should use them for programming.
SCREW the text editor based programming.
I think this is one of those rites of passage all experienced programmers probably go through. At some stage, your experience of different languages gets to the point where you understand that the underlying concepts transcend the syntax of any specific language. A natural next step, particularly if you've seen the sort of parsing graphs used by compilers, is to assume that throwing out the "awkward" text syntax in favour of some whizzy graphical scheme will make things much easier. Some people have even done PhDs on this subject.
Unfortunately, when you try it in practice, you find it's not nearly as clear-cut as you thought. Like all that nasty, unnecessary punctuation found in many programming languages, it turns out that using a concise, precise text format is often far easier both to read and write than any graphical alternative. What can be done in one line of regex in Perl takes a whole screen of graphical representation via flow charts and state machines.
I wish you luck in your exploration of graphical alternatives, but I'm afraid the odds are pretty heavily that after a while, you'll come full circle, and understand that all that nasty "bracket crap" is there for a reason, and has survived for decades because that reason is sound.
Mozilla's security record is no-where near as bad as IE's is - and won't get that bad, ever, due to different design decisions - whether its as popular as IE is, or not.
Y'see, the problem is that statements like that just don't have any credibility left when you're looking at vulnerabilities like this. The bug in question is a "complete wipe-out" style vulnerability. The issue was known by the Moz dev team years ago, and they decided it was WONTFIX. Yet even IE fixed this one a while back.
The problem here is not the specific bug, it's the attitude/lack of awareness demonstrated by the Mozilla dev team when faced with a critical vulnerability. The attitude of so many people in this thread -- "It's a Windows fault, not our precious Mozilla!" -- is almost as scary.
Sorry guys, the honeymoon's over. Mozilla can crash, can take out all your stored e-mail, can be exploited to damage the rest of your system, and doesn't get fatal security flaws fixed for years, just like IE. It may still be a better product, but there's no mileage left in claims that it will always and necessarily be so.
BTW, assuming there are no exploits out there for this vulnerability is staggeringly naive. Just because no widespread worm/virus-style exploits are known doesn't mean it hasn't been used by the geek who disliked the other guy down the hall or by the company emloyee wanting a quiet raise.
I'm still using Moz 1.5 on Windows[1]. I can't find any information about which versions of Moz contain this vulnerability, nor any information about whether the patch provided applies. Given that 1.5 isn't exactly an old version by any real-world standards, it's disappointing that it (and other recent releases apart from the latest) appear to be so poorly supported. Can anyone provide more information for these apps?
[1] This is mostly because I tried to install 1.6 when it was first released, and it irretrievably toasted my e-mail database and profile. FWIW, I'd successfully installed every.x version since 1.1, so I had some clue what I was doing. It was just broken, seriously enough that I will no longer trust updates to the Mozilla tree. I'm now waiting for Firebird/Thunderbird to reach official release, in the hope that tools for migrating Mozilla profiles to those apps will be independent and thoroughly tested.
Now, I'm not a professional literary critic anymore, but I do know that in order to fully understand a plot, one must read a work in its entirety. You admit to only having read 1/4 of the book, and then you trash it?
Yes, and while I take your point, in this case I stand by that comment. What good is the last 3/4 of a book, if the first 1/4 is so dull that people put it back on the shelf before getting that far? This is my point about this book: I've read good books and bad books, books that grip you so you can't put them down and books that are so-so and need taking in small doses, but I've never in my life read any other book that I found so completely, purely, terribly boring that I just couldn't concentrate to read another page.
Are you really telling me that 1/4+1 page through the book, the writing style becomes interesting, the vocabulary expands beyond that of a five-year-old, the ideas go beyond the mundane, and it develops some sort of originality and interest? That would be a truly remarkable transformation from the dull, plotless, childish narrative I slogged through for the first pages.
Sorry to go on, but please understand that you're talking about the book that almost single-handedly annihilated my faith in any sort of "quality" English literature for more than a decade. If that makes me uncultured, I'll take my "poor" contemporary thrillers, sword and sorcery fantasies, science fiction, and non-fiction over anything an English Lit class could offer me any day, thanks.
Skilled tradesmen are generally self-employed or working for a small business, and as such they provide for themselves. They are also their own bosses. They can set whatever rate they think they will get hired at -- and if you need a plumber at 3am, you can bet that's going to be nice and high -- and they take it home, not some faceless boss figure.
When you're being employed by someone else, they're effectively taking most of the credit for the fruits of your labour. You can bet they're making more out of your work than you are, several times over. That being the case, you better believe they're going to be expected to cover the overheads, including sick leave, provision of tools, and so on.
Ahh the words of an hourly worker. [...] When one is a salary man, a bit more is expected, within reason (which is the key).
But why should it be? That's just a cheap excuse for employers to bias the deal so they can get more than they're entitled to: a fair day's work for a fair day's pay.
As you say, "within reason" certainly is the key, and in this case, the employer's behaviour is beyond contempt, and they deserve to lose every employee they've got, starting with the best. Fortunately, when employers get this screwed up, that's usually what happens.
If we're talking about computing books here, I'd definitely second this one. I wouldn't recommend it just because it provides valuable insights for C++ developers, though it certainly does do that. Far more importantly, it provides valuable insights into the sorts of decisions and compromises required to plan, implement, and refine a successful, world-class product with a wide market and conflicting requirements. There are few true success stories in this business, but any way you look at it, C++ is one of them, and as this book clearly explains, that wasn't an accident. A lot of developers would do well to come down from their ivory towers for long enough to read this book.
A journey in coming to grips with the real world and finding your place in it.
Or a brilliant example of literary critics completely losing the plot and advocating a truly pathetic work as some sort of classic, depending on your point of view.
Catcher in the Rye is the only book I have ever found so completely impenetrable that I literally couldn't bring myself to read another page, and I wasn't even 1/4 of the way through when that happened. Given that it was one of the set texts for my English examination, that was unfortunate, but true nevertheless.
The book has all the style and substance of a piece about "my family" written by an eight-year-old. I have nothing against eight-year-olds writing, but would you proclaim them classics and put their writings on the book list for an academic course in English? No, you wouldn't. So why is Catcher in the Rye there?
I'm sure the 100 things I'd do if I were an evil overlord has been done. I definitely remember something about not interrogating the hero in the heart of my secret underground base...
Given that the key point of refactoring is that the behaviour remains unchanged after the structure is improved, that might not be a great branding exercise...
Maybe trying to make a point that the writer of the article doesn't really know much about X-window, so he calls it X-windows (a common mistake).
I work in an office full of UNIX veterans. We run about half a dozen different flavours of UNIX on various systems, and have machines running more than a dozen different operating systems in total set up to communicate across a network and run various apps remotely.
Everybody in my office calls it X-Windows. I'm sure they'd all be suitably impressed with someone who either thought that was a mistake (it may be a colloquialism, but it's a near-universal one) or thought that picking on the name meant they didn't know how it works.
How many of these compilers will you find on the Windows installation disk? None. Linux on the other hand ships with compilers as standard.
Yep, us stupid Windoze lusers aren't clever enough to recompile our kernels every 24 minutes, so we have to install ready-made software that just works instead. What a stoopid idea.:-)
Slashdot Mirror
That's true, of course, but the point here is that Windows Update does give them to me for IE. Even if I'm not using the most up-to-date version, I still get patches for critical vulnerabilities, and they still get sent to my notifications tray automatically if Windows Update is on.
My objection here is that, as a Mozilla 1.5 user, I couldn't find any information on whether this vulnerability affected me (aside from a one-liner I eventually found deep within Mozilla's site that said "versions up to 1.7") or any information at all on what I needed to do to fix it in 1.5. As a programmer, I can extrapolate from the descriptions I have seen, but none of this would help Joe Family-Member who I'd convinced to switch to Moz when 1.5 was current.
I like them too; that's why I use Mozilla. And for the avoidance of doubt, I think the dev team on the whole do a great job, and I'm grateful for their efforts. I've just seen them drop the ball in a Very Bad Way twice too often now -- once to stop me upgrading, and again in apparently not supporting the "old" version -- and I'm starting to get worried. As a geek, I can understand that, and tolerate it. It's just a shame for the mainstream, because it reduces what should be a superior solution to the level of IE/Outlook.
I did back everything up, which was fortunate since I needed to restore from that backup immediately.
However, my faith in the system is now shaken beyond repair. Upgrade instructions for Mozilla versions have always been pretty useless, and a screw up that spectacular in a straightforward upgrade betrays underlying weaknesses that are scary in any application that I'm going to depend on.
The more scary thing, however, is that the attitude appears to be that "old" versions are not supported. That's a very "open source, update from the CVS tree every night" attitude, but has no place in the real world. Given that this is software with an age best measured in months, that's a fairly serious flaw as far as making it into the mainstream -- most people aren't going to upgrade their Mozilla versions regularly, if at all.
No, I'll wait for Thunderbird/Firefox to hit 1.0 and then move, but I won't upgrade Mozilla again. In the meantime, I'll have to try and work out how to patch this up in 1.5, and if anything serious happens, I'll go back to IE.
I totally agree about functional languages and monads. They're theoretically elegant solution to a major practical problem, but always seem far too awkward in actual use (though I'm no expert on this subject).
What I'd like to see is the reverse approach: an imperative language that supports higher-order functions, currying, etc. properly. I don't see any problem with this approach, yet the most (only?) serious attempt to bridge the imperative/functional gap so far seems to be OCaml, which starts from a functional approach and adds imperative-like features (and, IMHO, not particularly cleanly). One need only look at the flexibility evident in scripting languages that provide basic support for functional programming concepts to see the potential.
That's true, of course, up to a point. They're certainly very useful things. The problem is they're so awkward, both to write and to use. Compare something like this fairly typical C++ style:
with this fairly typical ML style (neglecting the fact that you'd probably do this with a higher-order function in such a language anyway):
The combination of type inference, implicit genericity, and pattern matching in the functional version makes for much more concise code.
That's true, if inadvertent. However, at the risk of using an old cliche, look at LISP if you want to see what metaprogramming can really do.
Finally, regarding Ruby blocks, what does that approach offer over a fairly common idiom (in random pseudo-code):
or the obvious functional version:
The technique is useful, but I don't see why Ruby's blocks offer anything new or different. Am I missing something here?
This is certainly true to a point. There are three basic kinds of data used throughout the programming world: text, numbers and logic (true/false). Pretty much any mainstream general-purpose language provides basic arithmetic and logical operators, and then an extensive library of more advanced mathematics functions. With strings, you often get basic operators, but beyond those there's a world of difference between providing a couple of upper-/lower-case conversions and having things like regular expressions supplied as standard.
I think part of this problem is that what constitutes good support for strings isn't nearly as clear-cut as it is with numbers. Should we provide mutable and non-mutable types? How much should the regexes support? How do we deal with international issues?
The latter is a biggie that I think will become more significant as time goes on and markets expand worldwide. Frankly, most languages suck when it comes to dealing with translating text and working with foreign languages. Consider how many provide a function mapping a character onto its upper-case equivalent; what it's supposed to do with a German double-s? Some languages get text support spectacularly wrong: C++'s much heralded IOStreams system codifies structure that should be data, and thus makes itself almost completely useless for any sort of internationalised development; all the locales in the world won't change the fact that different languages use different word order conventions.
I think the underlying problem here is that text is fundamentally a complicated thing. Numbers, whether integers, fixed- or floating-point, have fairly well-defined rules (though as any numerical analyst will tell you, they don't necessarily match those of mathematics). Text, however, is on a different level. Even dealing with simple concepts like a case-insensitive comparison (assuming your input language even has cases in this sense) can be hugely complicated in practice, and complications like multiple word-forms multiply up to make it many times more difficult than typical mathematical code. It's more like expecting calculus to be built into a simple programming language, except that relatively few apps need that level of maths, while just about anything with a UI potentially needs that level of text support.
Even if you're only dealing with manipulations of well-structured text in a single language, not all processing fits neatly into the idioms offered by regular expressions. Regexes are powerful tools, to be sure, but I think we're still waiting for the not-quite-silver bullet in text processing to arrive. I expect this to be something based on higher level concepts than a simple list of characters, possibly to be very demanding of processing power (though viable with tomorrow's technology), and probably to revolutionise the international development community like nothing we've ever seen before.
So yes, I agree completely, good text processing is a very important feature for a programming language. If only any of them had it... ;-)
You mean like the whole concept of declarative programming, as seen ubiquitously in the functional and logical language worlds?
Question your musical taste? ;-)
Well, it allows you to return function pointers, which certainly have their uses. However, your program has eight non-trivial lines of code, but would be written in around three lines in just about any language supporting serious functional idioms, something like this (in random functional pseudo-code):
Such features, having much simpler syntax, would also be immune to the error involving pointer notation that you made. Moreover, a compiler that understands functions to this level would almost certainly reduce this to main being the print expression, which no C optimiser is likely to do in your case.
Your simple example is a perfect demonstration of exactly why C sucks in this particular respect.
I'll go with the lambda function bit, but I'm not entirely convinced by the rest. :-)
I rather unsubtly advocate C++ around these parts from time to time, but that's because I think it's incredibly well-engineered for a real-world tool. It has a lot of "powerful enough" features, and you can get work done with it. However, if we're talking about favourite features for a language, presumably we're going for ideals, in which case frankly C++ sucks on most counts: its OO features can be cumbersome to use; its generics are child's toys compared to those in other languages; its syntax generally is terrible; and it's missing any serious support for functional idioms.
Ruby blocks are, as far as I can tell, just a rather unusual syntax for fairly routine concepts. Quite a few people seem to like them, so I assume they do their job well in the context of Ruby as a whole, but what's special about them that a dozen other languages can't do in their own way?
Lazy evaluation is an intriguing concept, but suffers from the classic flaw of many purely functional languages: in realistic problems, things don't run on abstract machines in isolated worlds, and a certain level of determinism is required to get things done. I've yet to see a really compelling example of code that is particularly elegant or efficient using lazy evaluation, but can't be written similarly elegantly and efficiently using some sort of generator/iterator idiom and perhaps a basic optimiser.
Lambda functions, and in fact the whole family of related concepts -- higher-order functions, currying, anonymous functions, closures -- just make life so much easier. Working in languages that provide at least modest support for these ideas (in the sense of, say, Perl rather than ML or Haskell) always seems less like hard work than using something like C++, where the closest you get is some template wizardry which, looked at objectively, is pretty much off the scale at the wrong end. Functional idioms rock, and why no-one has yet produced a solid imperative language that integrates these features cleanly and comprehensively I do not know...
I think this is one of those rites of passage all experienced programmers probably go through. At some stage, your experience of different languages gets to the point where you understand that the underlying concepts transcend the syntax of any specific language. A natural next step, particularly if you've seen the sort of parsing graphs used by compilers, is to assume that throwing out the "awkward" text syntax in favour of some whizzy graphical scheme will make things much easier. Some people have even done PhDs on this subject.
Unfortunately, when you try it in practice, you find it's not nearly as clear-cut as you thought. Like all that nasty, unnecessary punctuation found in many programming languages, it turns out that using a concise, precise text format is often far easier both to read and write than any graphical alternative. What can be done in one line of regex in Perl takes a whole screen of graphical representation via flow charts and state machines.
I wish you luck in your exploration of graphical alternatives, but I'm afraid the odds are pretty heavily that after a while, you'll come full circle, and understand that all that nasty "bracket crap" is there for a reason, and has survived for decades because that reason is sound.
Y'see, the problem is that statements like that just don't have any credibility left when you're looking at vulnerabilities like this. The bug in question is a "complete wipe-out" style vulnerability. The issue was known by the Moz dev team years ago, and they decided it was WONTFIX. Yet even IE fixed this one a while back.
The problem here is not the specific bug, it's the attitude/lack of awareness demonstrated by the Mozilla dev team when faced with a critical vulnerability. The attitude of so many people in this thread -- "It's a Windows fault, not our precious Mozilla!" -- is almost as scary.
Sorry guys, the honeymoon's over. Mozilla can crash, can take out all your stored e-mail, can be exploited to damage the rest of your system, and doesn't get fatal security flaws fixed for years, just like IE. It may still be a better product, but there's no mileage left in claims that it will always and necessarily be so.
BTW, assuming there are no exploits out there for this vulnerability is staggeringly naive. Just because no widespread worm/virus-style exploits are known doesn't mean it hasn't been used by the geek who disliked the other guy down the hall or by the company emloyee wanting a quiet raise.
I'm still using Moz 1.5 on Windows[1]. I can't find any information about which versions of Moz contain this vulnerability, nor any information about whether the patch provided applies. Given that 1.5 isn't exactly an old version by any real-world standards, it's disappointing that it (and other recent releases apart from the latest) appear to be so poorly supported. Can anyone provide more information for these apps?
[1] This is mostly because I tried to install 1.6 when it was first released, and it irretrievably toasted my e-mail database and profile. FWIW, I'd successfully installed every .x version since 1.1, so I had some clue what I was doing. It was just broken, seriously enough that I will no longer trust updates to the Mozilla tree. I'm now waiting for Firebird/Thunderbird to reach official release, in the hope that tools for migrating Mozilla profiles to those apps will be independent and thoroughly tested.
Yes, and while I take your point, in this case I stand by that comment. What good is the last 3/4 of a book, if the first 1/4 is so dull that people put it back on the shelf before getting that far? This is my point about this book: I've read good books and bad books, books that grip you so you can't put them down and books that are so-so and need taking in small doses, but I've never in my life read any other book that I found so completely, purely, terribly boring that I just couldn't concentrate to read another page.
Are you really telling me that 1/4+1 page through the book, the writing style becomes interesting, the vocabulary expands beyond that of a five-year-old, the ideas go beyond the mundane, and it develops some sort of originality and interest? That would be a truly remarkable transformation from the dull, plotless, childish narrative I slogged through for the first pages.
Sorry to go on, but please understand that you're talking about the book that almost single-handedly annihilated my faith in any sort of "quality" English literature for more than a decade. If that makes me uncultured, I'll take my "poor" contemporary thrillers, sword and sorcery fantasies, science fiction, and non-fiction over anything an English Lit class could offer me any day, thanks.
Skilled tradesmen are generally self-employed or working for a small business, and as such they provide for themselves. They are also their own bosses. They can set whatever rate they think they will get hired at -- and if you need a plumber at 3am, you can bet that's going to be nice and high -- and they take it home, not some faceless boss figure.
When you're being employed by someone else, they're effectively taking most of the credit for the fruits of your labour. You can bet they're making more out of your work than you are, several times over. That being the case, you better believe they're going to be expected to cover the overheads, including sick leave, provision of tools, and so on.
But why should it be? That's just a cheap excuse for employers to bias the deal so they can get more than they're entitled to: a fair day's work for a fair day's pay.
As you say, "within reason" certainly is the key, and in this case, the employer's behaviour is beyond contempt, and they deserve to lose every employee they've got, starting with the best. Fortunately, when employers get this screwed up, that's usually what happens.
If we're talking about computing books here, I'd definitely second this one. I wouldn't recommend it just because it provides valuable insights for C++ developers, though it certainly does do that. Far more importantly, it provides valuable insights into the sorts of decisions and compromises required to plan, implement, and refine a successful, world-class product with a wide market and conflicting requirements. There are few true success stories in this business, but any way you look at it, C++ is one of them, and as this book clearly explains, that wasn't an accident. A lot of developers would do well to come down from their ivory towers for long enough to read this book.
Or a brilliant example of literary critics completely losing the plot and advocating a truly pathetic work as some sort of classic, depending on your point of view.
Catcher in the Rye is the only book I have ever found so completely impenetrable that I literally couldn't bring myself to read another page, and I wasn't even 1/4 of the way through when that happened. Given that it was one of the set texts for my English examination, that was unfortunate, but true nevertheless.
The book has all the style and substance of a piece about "my family" written by an eight-year-old. I have nothing against eight-year-olds writing, but would you proclaim them classics and put their writings on the book list for an academic course in English? No, you wouldn't. So why is Catcher in the Rye there?
I'm sure the 100 things I'd do if I were an evil overlord has been done. I definitely remember something about not interrogating the hero in the heart of my secret underground base...
Given that the key point of refactoring is that the behaviour remains unchanged after the structure is improved, that might not be a great branding exercise...
It certainly is (although no more offensive than implying that India is a third-world country).
I work in an office full of UNIX veterans. We run about half a dozen different flavours of UNIX on various systems, and have machines running more than a dozen different operating systems in total set up to communicate across a network and run various apps remotely.
Everybody in my office calls it X-Windows. I'm sure they'd all be suitably impressed with someone who either thought that was a mistake (it may be a colloquialism, but it's a near-universal one) or thought that picking on the name meant they didn't know how it works.
He's not criticising, he's just saying you have to pay to get it in a usable form... which you do, whether through bandwidth or buying a distro on CD.
Yep, us stupid Windoze lusers aren't clever enough to recompile our kernels every 24 minutes, so we have to install ready-made software that just works instead. What a stoopid idea. :-)
for /F "delims=" %a in ('date /t') do set today=%a
Of course, in reality you just use the %DATE% pseudo environment variable instead of the rather sledgehammer-like effort above.
...Has anyone ever seen John Ashcroft and Comical Ali at the same time?