Cant it be argued that Google, Microsoft's "Search" on the start menu, and any other index or search application also would be contributary?
It can very sensibly be argued. However, in those cases there is a clear counterargument: most uses of those services are not to breach copyright, and everyone in court knows (or could check) this.
The questions here are things like whether those guys should have known the purposes for which their P2P networks would be used, and whether there was a plausible alternative reason for that network to be there. If they knew damn well that they were helping out with breaches of copyright and they had no other reason to do it, well, that's a pretty open and shut case. If not, they have a defence.
As much as some geeks here might like to believe otherwise, legal systems are often fairly reasonable: if you have a good reason for doing something, you'll generally get credit for it, while if you're blatantly trying to work around the spirit of the law on some pathetic techie point, they'll send you down. There are problems when the laws behind that system are way out of line, but as far as I can see from what I've read, that wasn't the case here: they were running networks being used for wholesale copyright breaching and not a whole lot else. If they'd been using them to distribute Linux patches or freely available demos for the next big FPS, that would be different, but as far as I can tell from the reports, they weren't.
If Passport were being used for copyright protection, it would be a federal crime to report this security vulnerability.
It might be a federal crime in the United States, but fortunately, most of the rest of the world has a smarter legal system. Or perhaps the US government plans to block all incoming traffic from outside, so no-one can read the EU- or Asian- or Australian-based news sites and see this for themselves...?:-)
I wasn't giving a review of the GIMP, I was providing a deliberately biased point of view to counteract your heavy advocacy. I pretty much said that in my first sentence.
It seems to me that your little mini-review is an attempt at avoiding the real issues of the capability and usability of the GIMP. Would you think I was fair if I judged Office XP based on it's performance under Wine and how well it meshed with my UNIX desktop? Of course not. Likewise, your review of GIMP on Windows tackled none of the real issues of image manipulation.
Had I been giving a proper, objective review, I might have contrasted it with something like Paint Shop Pro, the closest equivalent tool in common use on Windows (and something that, while not free, costs almost nothing in business terms). I would have noted that the GIMP is missing several useful filters, seems to have quite limited text handling, has a liability in that it can't export GIFs without hackery, etc. I would also have commented on its strengths to balance the view.
That isn't really the point, though. I wouldn't think it was fair for you to judge Office XP based on its performance on Linux, but then I don't see a whole bunch of slashbots advocating such a use every day on this site. I do get told of the virtues of moving to open source software, specifically on a Windows platform, quite frequently here, and Moz, OpenOffice and the GIMP are the three most often-cited examples.
This is a thread all about debunking the myths, allegedly about Linux but in practice about the whole open source world, since to many businesses they are (rightly or wrongly) treated as synonymous. There's even a claimed myth in the original article on this point.
Now, look at your posts in this thread. One minute you complain that the lack of FPS games isn't relevant to a business user but the next you're criticising Windows because it doesn't have a built-in ability burning VideoCDs. The latter isn't relevant to typical businesses either, and you'd get software that could do it with just about any CD-R drive you bought today anyway. (We can get into the whole supporting hardware within a useful timeframe argument if you really want.) Hell, you even wrote:
For _businesses_ running Linux, it is a big deal.
That was about terminal emulation. The thing is, you put the emphasis in the wrong place. It should have said "For businesses running Linux, it is a big deal." That would have demonstrated how one-sided the argument was, and how irrelevant to a typical Windows-based outfit.
Your original post some way up did grossly misrepresent the capabilities of Windows compared to Linux, whether you're talking generally or business-specifics, as was pointed out to you by another poster. Your follow-up did then fail to give a convincing response to several of the objections raised. Yes, my post was biased, as it admitted and was intended to be, but the point was a fair one.
I've generally been much happier with Moz and OpenOffice, and I continue to use them rather than the MS equivalents because (a) I don't believe in ripping software, even MS', and (b) I want to support the alternatives, because I think they have a lot of potential. That doesn't mean they are as good or better yet, though.
However, as I've explained in posts here before, Moz does have some serious stability issues on Windows, and the idealistic rather than realistic attitude of the developers towards standards hurts rather than helping at times. The big killer, though, is that if things go wrong, you can wind up with your whole profile screwed, resulting in much lost time recovering (if you can) your mailbox, address book, etc. The fact that it doesn't seem to work as intended when moving the folder where your files are stored is also a big downer; I'd like to have Moz installed on both Windows and Linux and then switch seamlessly between the two so they
I fail to see how indexing public shares is in violation of copyright.
I didn't say it was. I'm not going to argue with someone putting words under my fingers.
Certainly they are responsable for any copyrighted materials they might have been sharing. but the indexing is not.
You guys really need to understand the concept of contributary negligence. If someone is doing something wrong, and you are knowingly helping them to do it when you have a reasonable alternative, then you are also doing something wrong. You may not be guilty of the same crime as them, but what you are doing is still wrong.
I suppose you thought the initial amount the RIAA was demanding was fair as well.
No, it was absurd. The fact that I think these kids probably got what they should have known was coming to them does not mean I am a slave to the RIAA, or that I approve of complex monopoly abuse. My point was that there are good ways to do something about that sort of thing and bad ways. These guys went for a bad way, and paid for it. Case closed, next.
Do you think 32 40X cd-r drives are actually 1280 cd-r drives?
No, but the whole "private use is OK, a couple of copies to buddies doesn't do any harm" argument is completely bogus. How long does it take to copy an album via P2P over broadband? A few minutes? If you gave a copy of something to just five of your friends, and they each gave a copy to five of their friends, and so on, you'd reach the entire population of the US in about 12 hops. IOWs, even with very limited individual distribution, anyone who wanted an illegal copy would probably have one within a day of one person getting hold of it.
Damn, I wish we'd had this thread at the end of last year. After a period of inactivity due to injury, I also wanted to keep track of things as I got back into shape. I set up an Excel spreadsheet back in January, tracking my daily food intake (including calories, amount of protein, carbs, fat and fibre, and how many portions of fruit and veg I was getting each day), my daily exercise (counting anything lasting more than a quarter hour or more as significant) and my daily weight. Would have been a whole lot easier to do the daily food intake sheet if I'd been able to find these resources back then, instead of just the few odd tables you get from a typical web search!
OK, since you sing the praises for the GIMP so much, I feel compelled to offer a balancing view.
Last week, I wanted to produce a small logo to go on a web site. I had no graphics software installed on my WinXP box, so I decided to go find and install this "GIMP" thing I'd heard so much about.
After nearly an hour of searching (some of us are still stuck with 56k modems...) I finally found a site that offered something close to a proper installer for the GIMP, as opposed to a huge list of random-sounding packages, which I'm somehow supposed to understand well enough to choose which to install.
Unfortunately, the installer only installed a prerelease version. That's OK, I thought, prereleases of open source things happen all the time, it's their version of a "beta test". Might be a few little bugs, but it'll be pretty stable and mostly work. Wrong!
So, having run two installers (apparently just one isn't good enough for the GIMP) I fired up the app.
Yuck. It may be great on Linux, I don't know, but on Windows, its interface is hideous. Nothing follows any of the usual standards. I found it awkward and inefficient, and it took me several minutes just to work out how to put a letter "a" in a font I wanted onto my image.
Then I tried to save that, but unfortunately, the export filter for one of the most common filetypes around crashed the whole app on me, losing everything.
I won't bore you with the next three times it crashed doing the most basic of things; most open source advocates would just say "Oh, it's a prerelease, it's your own fault" anyway.
So, here we have an application that is impossible for a non-expert to install, which breaks just about every UI convention in the book, and which is waaaaaay behind typical Windoze utilities like Paint Shop Pro on all counts. Sure, it's free, but so is Windows Paint, and at least I managed to get an "a" into a file on disk with that. Me, I'll go out and spend my pennies to buy the current version of Paint Shop Pro if I need to do non-trivial graphics work, thanks.
I've now tried OpenOffice, Mozilla and the GIMP, three bastions of the OS world, and found all of them still to be some way behind their commercial rivals. Is it any wonder, then, that the advocates of tools like Linux are starting to find themselves up against a more sceptical market just as things seemed to be taking off?
Most interviewers these days ask things like, "tell me about a situation where there was a conflict and how you handled it". Tech questions are maybe about 25% of the interview on average, and the tech questions are usually odd or dumb. (I personally don't believe you can assertain somebody's tech ability in 40 minutes.)
While I agree with you on the 40 minutes thing, I suspect you're overgeneralising on the nature of tech firms' interviews. To join my current employer, I had to attend two interviews. The first was with my current team leader and the head of the development group. We discussed my background a bit to give them an idea of what "I can program Language X" and "I've used platform Y" actually meant, and then moved right along to looking at a simple but realistic problem in the field to see if I understood it and could solve it, and then writing a simple function to output the answer. It was nothing earth-shaking, but it was a genuine representation of a typical task I now perform in my job. The second interview was with the head of the development group again plus the MD, and was basically about personal and business issues.
I think perhaps this is the sort of thing you only really find in smaller businesses these days. In the big name multinational corps, you probably get your CV sorted by some ignorant database, then reviewed by some ignorant HR pro, and then you get some sort of oh-so-clever but actually pretty useless interview that boils down to whether or not your personality matched the interview panel's. Too bad, because obviously the process I went through is far more sensible; I work in an office full of good guys who know their stuff and have a professional attitude, which seems to be better than a lot of the big places if the anecdotes all over/. are anything to go by. It's no wonder that the greatest successes of the past few years mostly seem to be smaller businesses, as well as the big failures.
Re:linux has no features I see in the screenshots
on
Looking at Longhorn
·
· Score: 1
Thanks for the info. My old Win2K machine at work used to take 30+ seconds to boot into a useable state, which was a great improvement on earlier versions, but still annoying. My new work machine, and my home box, both run WinXP and boot much faster than 2K as mentioned. If a fairly minimal Linux installation (I'm the kinda guy who wants to core OS, plus basic libraries and specific apps, and nothing else) can boot in that sort of timeframe, I'll be happy. Thanks again for the info.
Re:linux has no features I see in the screenshots
on
Looking at Longhorn
·
· Score: 1
kdm. Easy to configure, many useful options. You can even configure it to log you in automatically. Switch on your machine, go make coffee, come back, you're logged in and ready to start work, your previous session restored.
Is this a joke, or for real? My WinXP boxes at home and work both go from powered off to waiting in about 10 seconds. The only recent Mac I have regular access to isn't far behind.
My new PC is all set up ready to install Linux as a dual-boot option as soon as it can support my hardware, at which point the idea would be to move all of my "serious" work onto Linux and just use WinXP for games. I'm just um-ing and ah-ing about when to move, but hearing too many little things like this makes me stop and think about whether I want to do it at all.:-(
A lot of software is written in an environment where it is reasonable to trust your sources
No, it isn't. User input is never trusted.
If you'd bothered to read the rest of this thread, you'd have spotted that we're not talking about end-user software here, but libraries. And in that case, yes, it is.
I guess I look at maintenance and integration issues in development, more than some people do, because of my background in DVT and QA.
For the record, that library software you reckoned should be shunned goes through the most extensive set of automated tests I've ever seen every night. Every new feature and every bug that gets reported get their own test(s), and the slightest change in the huge amounts of diagnostic output produced is cause for concern and investigated. Many of our algorithms get mathematically proved for correctness before being allowed into the code. We have pretty decent coding standards and people discuss changes with colleagues to get second (and third...) opinions before modifying things. Some of our clients even get pre-released versions, to check the integration works with their software before the final product ships. Basically, the chances of finding a genuine crash bug -- or even a logic error giving the wrong answer, for that matter -- in our library if it's used as the documentation says it should be is almost zero. On the rare occasions it does happen, a bug fix is often shipped to the affected client(s) the same day.
Now, if you're a guy who knows about QA, you should appreciate that these standards are higher than almost anywhere in the software development industry. They have to be, given the number of different clients who use our library in their product, and the number of our clients' clients who therefore depend on it. If you still think software like this should be shunned in favour of something that runs a bazillion times slower but that happens to catch some (not all) of the bad input cases you could give it, that's up to you, but I suspect the vast majority of professionals in the field would disagree with you.
Again, I'm speaking only for myself here, and not my employer.
My generalization used the word "crash". We don't speak of libraries crashing, only applications.
OK, if that's your frame of reference, I don't have such a problem with the statement.
I should have mentioned that your company's product is a prime example of a library that has a good excuse for not being bulletproof. Math APIs are often used in tight loops in massive calculations. Adding failsafe logic may only degrade a call slightly, but when that call gets made a gazillion times, even a tiny loss of performance can get expensive.
I agree entirely that it is bad if an end-user application falls over inappropriately. I just disagreed with your generalisation, because not all software that's written is an end-user app. In some cases, your design goals don't include, or outright conflict with, complete error checking.
You can determine that some inputs will execute to completion.
That is true, of course. But what do you do if your algorithm is O(n) but the algorithm to check it will terminate with a reasonable result on bad input is O(n^3)? Do you really think my users want me to force this check on them?
A program with the purpose of processing data which is 99.9% from untrusted sources should under no circumstances crash due to malformed data.
That may well be a sensible design decision. However, the "untrusted sources" part is significant. A lot of software is written in an environment where it is reasonable to trust your sources, and in those cases, it may be undesirable to introduce slow error-handling code. The post to which I first objected claimed that in general it was true that any software that could crash had a bug, and in this environment that is simply not the case.
... so many apps use browsers as a front end is indicative of the fact that... there wasn't a reasonable graphical application interface for use with clients that don't involve installing software.
I agree with you about browser front ends... they're overused in all sorts of inappropriate places. Frex, a friend just got a new LinkSys switch -- and to access its configuration requires a JAVASCRIPT-ENABLED browser.
Absolutely. Was there something wrong with providing a control app and a simple protocol to set it up, as everyone always used to?
A company I used to work for produced, amongst other things, control software for networking infrastructure, and web apps. I imagine that had they ever been asked to do both at the same time, someone would have suggested this might not be a good idea(!).
No software should respond in an astonishing way when fed valid data that is outside of the domain of the function -- it should do range-checking and set an appropriate error flag and return to the caller with something, even if that "something" is a NAN.
Please tell me you're not just talking about things like forgetting to check before dividing by zero or SQRTing a negative number! If you are, then you are totally misunderstanding this conversation. We're in a different league here.
Even when fed absolute junk, it should detect the junk and error out in a predictable manner.
Unfortunately, you've spent so long checking that your algorithm will work correctly and terminate (assuming such checks are even possible) that no-one else will ever use your code because the alternatives are several orders of magnitude faster, which is the dominant requirement for the type of software we provide.
Any library can get bad input. You can pass me a pointer to your data structure and claim it's valid, but actually give me an address outside of memory that I'm allowed to access so I segfault when I follow it. It is not possible to write a 100% bulletproof library in this situation.
You have to trust your calling code to do its job, and you have to be clear about what input you accept with defined results so those writing the calling code can do their job. There is no other option.
The only remaining question is how broad you choose to make the set of valid inputs. This is simply a trade-off between safety and performance, and in this particular industry, standard practice is to trust your caller and go for performance. You're necessarily relying on them to give you good input anyway, so further checks just slow you down without any real safety benefit.
In particular, taking down the application (and perhaps the entire system it's running on) is not an option.
Actually, taking down the whole application and providing diagnostics is one of the better options, since it makes it clear during testing that there is a bug, which in turn implies that our client application has a logic error somewhere in it.
If my library doing something can take down your whole system, your OS is broken, of course.
A library can simply document that it can't handle certain conditions and then expect the application developer to avoid those conditions before using functionality contained in the library.
Thank you. This was exactly my point.
In fact, this is often the only reasonable course of action, since the performance penalties associated with validating all input to the library at source can be prohibitive. Checking for a NULL pointer is easy. Checking the linked list you've given us isn't circular takes time. Checking the graph you've given us really is a DAG takes a lot of time. As someone else pointed out in this thread, checking some inputs would probably require solution of the Halting Problem.
I must disagree with you there, Anonymous Brave Guy. There is a difference between your library and IE. One is a library while the other is a user application. Clients of a library are other programs (code) that link to the library and make calls to it. The application programmers that use your library can be given an exact spec on 'defined' and 'undefined' usage of each of the library's functions/methods.
I don't think we're disagreeing at all. Your point is exactly the same as mine: the parent post to which I replied claimed that in general, crashing software always means a bug, yet under circumstances such as those you describe here, this may not the case.
Are we *that* confident in the maturity of our web browsers that causing a browser crash is nowadays considered a serious issue?
It shouldn't matter.
Browsers and the technologies on which they are fundamentally based were designed to allow the display of textual information in a somewhat formatted way. If the browser crashed, you should lose nothing but the page you were looking at, which you should be able to redisplay or display in another non-crashing browser just by opening up the address again.
The only reason browsers crashing matters now is because the industry has warped the technology and now tries to use it for totally unsuitable things. Browsers were never meant to be part of distributed applications where real data gets shifted around. The fact that so many apps now use a "browser" front-end is indicative of nothing but a poor choice of tool, as is the fact that crashes matter.
And in general, software should do something reasonable when it can't deal with input. Like deliver an error message. Crashing is always evidence of a bug, whether the data that caused it is buggy or not.
No, it's not.
I work on an industry-leading mathematical library. We rely, in a few places, on getting sensible input from our client apps. If they give us garbage, they have no guarantees about getting a sensible error back, or even about anything ever coming back.
Before you say that this sucks, consider that if we did completely error-check all input to ensure that everything terminated properly with the current data set yada yada, our performance would almost certainly take an unacceptable hit in each of these cases, and in this business, performance kinda matters.
In this case, crashing is not evidence of a bug, it's evidence of design priorities that don't match yours (but do match ours, and our customers').
(Obviously I'm speaking only for myself and not my employer here...)
Slashdot Mirror
It can very sensibly be argued. However, in those cases there is a clear counterargument: most uses of those services are not to breach copyright, and everyone in court knows (or could check) this.
The questions here are things like whether those guys should have known the purposes for which their P2P networks would be used, and whether there was a plausible alternative reason for that network to be there. If they knew damn well that they were helping out with breaches of copyright and they had no other reason to do it, well, that's a pretty open and shut case. If not, they have a defence.
As much as some geeks here might like to believe otherwise, legal systems are often fairly reasonable: if you have a good reason for doing something, you'll generally get credit for it, while if you're blatantly trying to work around the spirit of the law on some pathetic techie point, they'll send you down. There are problems when the laws behind that system are way out of line, but as far as I can see from what I've read, that wasn't the case here: they were running networks being used for wholesale copyright breaching and not a whole lot else. If they'd been using them to distribute Linux patches or freely available demos for the next big FPS, that would be different, but as far as I can tell from the reports, they weren't.
It might be a federal crime in the United States, but fortunately, most of the rest of the world has a smarter legal system. Or perhaps the US government plans to block all incoming traffic from outside, so no-one can read the EU- or Asian- or Australian-based news sites and see this for themselves...? :-)
And you thought a slashdotting was a heavy load... ;-)
I wasn't giving a review of the GIMP, I was providing a deliberately biased point of view to counteract your heavy advocacy. I pretty much said that in my first sentence.
Had I been giving a proper, objective review, I might have contrasted it with something like Paint Shop Pro, the closest equivalent tool in common use on Windows (and something that, while not free, costs almost nothing in business terms). I would have noted that the GIMP is missing several useful filters, seems to have quite limited text handling, has a liability in that it can't export GIFs without hackery, etc. I would also have commented on its strengths to balance the view.
That isn't really the point, though. I wouldn't think it was fair for you to judge Office XP based on its performance on Linux, but then I don't see a whole bunch of slashbots advocating such a use every day on this site. I do get told of the virtues of moving to open source software, specifically on a Windows platform, quite frequently here, and Moz, OpenOffice and the GIMP are the three most often-cited examples.
This is a thread all about debunking the myths, allegedly about Linux but in practice about the whole open source world, since to many businesses they are (rightly or wrongly) treated as synonymous. There's even a claimed myth in the original article on this point.
Now, look at your posts in this thread. One minute you complain that the lack of FPS games isn't relevant to a business user but the next you're criticising Windows because it doesn't have a built-in ability burning VideoCDs. The latter isn't relevant to typical businesses either, and you'd get software that could do it with just about any CD-R drive you bought today anyway. (We can get into the whole supporting hardware within a useful timeframe argument if you really want.) Hell, you even wrote:
That was about terminal emulation. The thing is, you put the emphasis in the wrong place. It should have said "For businesses running Linux, it is a big deal." That would have demonstrated how one-sided the argument was, and how irrelevant to a typical Windows-based outfit.
Your original post some way up did grossly misrepresent the capabilities of Windows compared to Linux, whether you're talking generally or business-specifics, as was pointed out to you by another poster. Your follow-up did then fail to give a convincing response to several of the objections raised. Yes, my post was biased, as it admitted and was intended to be, but the point was a fair one.
I've generally been much happier with Moz and OpenOffice, and I continue to use them rather than the MS equivalents because (a) I don't believe in ripping software, even MS', and (b) I want to support the alternatives, because I think they have a lot of potential. That doesn't mean they are as good or better yet, though.
However, as I've explained in posts here before, Moz does have some serious stability issues on Windows, and the idealistic rather than realistic attitude of the developers towards standards hurts rather than helping at times. The big killer, though, is that if things go wrong, you can wind up with your whole profile screwed, resulting in much lost time recovering (if you can) your mailbox, address book, etc. The fact that it doesn't seem to work as intended when moving the folder where your files are stored is also a big downer; I'd like to have Moz installed on both Windows and Linux and then switch seamlessly between the two so they
I didn't say it was. I'm not going to argue with someone putting words under my fingers.
You guys really need to understand the concept of contributary negligence. If someone is doing something wrong, and you are knowingly helping them to do it when you have a reasonable alternative, then you are also doing something wrong. You may not be guilty of the same crime as them, but what you are doing is still wrong.
No, it was absurd. The fact that I think these kids probably got what they should have known was coming to them does not mean I am a slave to the RIAA, or that I approve of complex monopoly abuse. My point was that there are good ways to do something about that sort of thing and bad ways. These guys went for a bad way, and paid for it. Case closed, next.
No, but the whole "private use is OK, a couple of copies to buddies doesn't do any harm" argument is completely bogus. How long does it take to copy an album via P2P over broadband? A few minutes? If you gave a copy of something to just five of your friends, and they each gave a copy to five of their friends, and so on, you'd reach the entire population of the US in about 12 hops. IOWs, even with very limited individual distribution, anyone who wanted an illegal copy would probably have one within a day of one person getting hold of it.
Damn, I wish we'd had this thread at the end of last year. After a period of inactivity due to injury, I also wanted to keep track of things as I got back into shape. I set up an Excel spreadsheet back in January, tracking my daily food intake (including calories, amount of protein, carbs, fat and fibre, and how many portions of fruit and veg I was getting each day), my daily exercise (counting anything lasting more than a quarter hour or more as significant) and my daily weight. Would have been a whole lot easier to do the daily food intake sheet if I'd been able to find these resources back then, instead of just the few odd tables you get from a typical web search!
OK, since you sing the praises for the GIMP so much, I feel compelled to offer a balancing view.
Last week, I wanted to produce a small logo to go on a web site. I had no graphics software installed on my WinXP box, so I decided to go find and install this "GIMP" thing I'd heard so much about.
After nearly an hour of searching (some of us are still stuck with 56k modems...) I finally found a site that offered something close to a proper installer for the GIMP, as opposed to a huge list of random-sounding packages, which I'm somehow supposed to understand well enough to choose which to install.
Unfortunately, the installer only installed a prerelease version. That's OK, I thought, prereleases of open source things happen all the time, it's their version of a "beta test". Might be a few little bugs, but it'll be pretty stable and mostly work. Wrong!
So, having run two installers (apparently just one isn't good enough for the GIMP) I fired up the app.
Yuck. It may be great on Linux, I don't know, but on Windows, its interface is hideous. Nothing follows any of the usual standards. I found it awkward and inefficient, and it took me several minutes just to work out how to put a letter "a" in a font I wanted onto my image.
Then I tried to save that, but unfortunately, the export filter for one of the most common filetypes around crashed the whole app on me, losing everything.
I won't bore you with the next three times it crashed doing the most basic of things; most open source advocates would just say "Oh, it's a prerelease, it's your own fault" anyway.
So, here we have an application that is impossible for a non-expert to install, which breaks just about every UI convention in the book, and which is waaaaaay behind typical Windoze utilities like Paint Shop Pro on all counts. Sure, it's free, but so is Windows Paint, and at least I managed to get an "a" into a file on disk with that. Me, I'll go out and spend my pennies to buy the current version of Paint Shop Pro if I need to do non-trivial graphics work, thanks.
I've now tried OpenOffice, Mozilla and the GIMP, three bastions of the OS world, and found all of them still to be some way behind their commercial rivals. Is it any wonder, then, that the advocates of tools like Linux are starting to find themselves up against a more sceptical market just as things seemed to be taking off?
While I agree with you on the 40 minutes thing, I suspect you're overgeneralising on the nature of tech firms' interviews. To join my current employer, I had to attend two interviews. The first was with my current team leader and the head of the development group. We discussed my background a bit to give them an idea of what "I can program Language X" and "I've used platform Y" actually meant, and then moved right along to looking at a simple but realistic problem in the field to see if I understood it and could solve it, and then writing a simple function to output the answer. It was nothing earth-shaking, but it was a genuine representation of a typical task I now perform in my job. The second interview was with the head of the development group again plus the MD, and was basically about personal and business issues.
I think perhaps this is the sort of thing you only really find in smaller businesses these days. In the big name multinational corps, you probably get your CV sorted by some ignorant database, then reviewed by some ignorant HR pro, and then you get some sort of oh-so-clever but actually pretty useless interview that boils down to whether or not your personality matched the interview panel's. Too bad, because obviously the process I went through is far more sensible; I work in an office full of good guys who know their stuff and have a professional attitude, which seems to be better than a lot of the big places if the anecdotes all over /. are anything to go by. It's no wonder that the greatest successes of the past few years mostly seem to be smaller businesses, as well as the big failures.
Thanks for the info. My old Win2K machine at work used to take 30+ seconds to boot into a useable state, which was a great improvement on earlier versions, but still annoying. My new work machine, and my home box, both run WinXP and boot much faster than 2K as mentioned. If a fairly minimal Linux installation (I'm the kinda guy who wants to core OS, plus basic libraries and specific apps, and nothing else) can boot in that sort of timeframe, I'll be happy. Thanks again for the info.
Is this a joke, or for real? My WinXP boxes at home and work both go from powered off to waiting in about 10 seconds. The only recent Mac I have regular access to isn't far behind.
My new PC is all set up ready to install Linux as a dual-boot option as soon as it can support my hardware, at which point the idea would be to move all of my "serious" work onto Linux and just use WinXP for games. I'm just um-ing and ah-ing about when to move, but hearing too many little things like this makes me stop and think about whether I want to do it at all. :-(
If you'd bothered to read the rest of this thread, you'd have spotted that we're not talking about end-user software here, but libraries. And in that case, yes, it is.
Sorry, but I think our support guys might be a tad upset if we took you on and so made one of them redundant!
For the record, that library software you reckoned should be shunned goes through the most extensive set of automated tests I've ever seen every night. Every new feature and every bug that gets reported get their own test(s), and the slightest change in the huge amounts of diagnostic output produced is cause for concern and investigated. Many of our algorithms get mathematically proved for correctness before being allowed into the code. We have pretty decent coding standards and people discuss changes with colleagues to get second (and third...) opinions before modifying things. Some of our clients even get pre-released versions, to check the integration works with their software before the final product ships. Basically, the chances of finding a genuine crash bug -- or even a logic error giving the wrong answer, for that matter -- in our library if it's used as the documentation says it should be is almost zero. On the rare occasions it does happen, a bug fix is often shipped to the affected client(s) the same day.
Now, if you're a guy who knows about QA, you should appreciate that these standards are higher than almost anywhere in the software development industry. They have to be, given the number of different clients who use our library in their product, and the number of our clients' clients who therefore depend on it. If you still think software like this should be shunned in favour of something that runs a bazillion times slower but that happens to catch some (not all) of the bad input cases you could give it, that's up to you, but I suspect the vast majority of professionals in the field would disagree with you.
Again, I'm speaking only for myself here, and not my employer.
OK, if that's your frame of reference, I don't have such a problem with the statement.
Exactly. :-)
I agree entirely that it is bad if an end-user application falls over inappropriately. I just disagreed with your generalisation, because not all software that's written is an end-user app. In some cases, your design goals don't include, or outright conflict with, complete error checking.
Not all software is written for end-users, or taking input from untrustworthy sources.
That is true, of course. But what do you do if your algorithm is O(n) but the algorithm to check it will terminate with a reasonable result on bad input is O(n^3)? Do you really think my users want me to force this check on them?
That may well be a sensible design decision. However, the "untrusted sources" part is significant. A lot of software is written in an environment where it is reasonable to trust your sources, and in those cases, it may be undesirable to introduce slow error-handling code. The post to which I first objected claimed that in general it was true that any software that could crash had a bug, and in this environment that is simply not the case.
There still isn't. That's kinda the point. :-)
Absolutely. Was there something wrong with providing a control app and a simple protocol to set it up, as everyone always used to?
A company I used to work for produced, amongst other things, control software for networking infrastructure, and web apps. I imagine that had they ever been asked to do both at the same time, someone would have suggested this might not be a good idea(!).
Please tell me you're not just talking about things like forgetting to check before dividing by zero or SQRTing a negative number! If you are, then you are totally misunderstanding this conversation. We're in a different league here.
Unfortunately, you've spent so long checking that your algorithm will work correctly and terminate (assuming such checks are even possible) that no-one else will ever use your code because the alternatives are several orders of magnitude faster, which is the dominant requirement for the type of software we provide.
Any library can get bad input. You can pass me a pointer to your data structure and claim it's valid, but actually give me an address outside of memory that I'm allowed to access so I segfault when I follow it. It is not possible to write a 100% bulletproof library in this situation.
You have to trust your calling code to do its job, and you have to be clear about what input you accept with defined results so those writing the calling code can do their job. There is no other option.
The only remaining question is how broad you choose to make the set of valid inputs. This is simply a trade-off between safety and performance, and in this particular industry, standard practice is to trust your caller and go for performance. You're necessarily relying on them to give you good input anyway, so further checks just slow you down without any real safety benefit.
Actually, taking down the whole application and providing diagnostics is one of the better options, since it makes it clear during testing that there is a bug, which in turn implies that our client application has a logic error somewhere in it.
If my library doing something can take down your whole system, your OS is broken, of course.
Thank you. This was exactly my point.
In fact, this is often the only reasonable course of action, since the performance penalties associated with validating all input to the library at source can be prohibitive. Checking for a NULL pointer is easy. Checking the linked list you've given us isn't circular takes time. Checking the graph you've given us really is a DAG takes a lot of time. As someone else pointed out in this thread, checking some inputs would probably require solution of the Halting Problem.
I don't think we're disagreeing at all. Your point is exactly the same as mine: the parent post to which I replied claimed that in general, crashing software always means a bug, yet under circumstances such as those you describe here, this may not the case.
It shouldn't matter.
Browsers and the technologies on which they are fundamentally based were designed to allow the display of textual information in a somewhat formatted way. If the browser crashed, you should lose nothing but the page you were looking at, which you should be able to redisplay or display in another non-crashing browser just by opening up the address again.
The only reason browsers crashing matters now is because the industry has warped the technology and now tries to use it for totally unsuitable things. Browsers were never meant to be part of distributed applications where real data gets shifted around. The fact that so many apps now use a "browser" front-end is indicative of nothing but a poor choice of tool, as is the fact that crashes matter.
No, it's not.
I work on an industry-leading mathematical library. We rely, in a few places, on getting sensible input from our client apps. If they give us garbage, they have no guarantees about getting a sensible error back, or even about anything ever coming back.
Before you say that this sucks, consider that if we did completely error-check all input to ensure that everything terminated properly with the current data set yada yada, our performance would almost certainly take an unacceptable hit in each of these cases, and in this business, performance kinda matters.
In this case, crashing is not evidence of a bug, it's evidence of design priorities that don't match yours (but do match ours, and our customers').
(Obviously I'm speaking only for myself and not my employer here...)