In theory? In a study of the average compiler? In a head to head comparison of the most popular JIT compiler with gcc? What?
Regardless of the performance issues the future of software development is going to be running non-native code on a virtual machine as this has so many advtantages including portability/distribution, security and efficiency of developing large scale systems.
Quite frankly, I don't see these advantages. It's trivial to recompile an app for each platform, and this is the most secure way to do things as well.
Another thing to note is that it was always possible to write more efficient assembler than C, but it was often easier to write more efficient C than assembler due to better code layout, easier management of libraries, code reuse and the manageability of developing larger apps.
You can write assembler in C, and seemlessly switch from one to another (nothing like the kludge of running native code with java). The vast majority of the time you don't need to though because the compiler will create the same machine code as your assembler would anyway. C is largely just a shorthand for assembler. So this is a terrible comparison.
Given that we want the security, stability, portability and other benefits that a virtual machine provides and that the virtual machine runs non-native bytecode and that the JIT is nearly as fast as compiled code and faster in some circumstances - compiling java code to native is pointless from a performance perspective in most practical cases.
Good JIT compilation requires a lot of memory and a significant amount of CPU. I don't see how you can say avoiding that overhead is pointless in all but the most trivial of circumstances.
In fact GCJ compiled java is usually slower than running under a modern JIT.
I don't deny that. Java wasn't meant to be compiled, and good compilers haven't been written for it. That's my whole point.
The reasons for compiling to native is probably more to do with the license restrictions on redistributing the Sun JVM. Due to the licensing restrictions most distros won't contain a full java implementation by default and therefore native comilation and the use of classlibrary may be the only way to conveniently redistribture your java on most linux distros.
Woohoo. Now I see what you mean about the many advantages in portability/distribution, security and efficiency.
In C, it requires almost no thought at all to write insecure code, and to do some things securely requires chunks of wrapper code around most things involving IO layers, wrapper code that is not program logic and can have bugs. In higher-level languages, the user won't be writing that code -- the engineers at Sun will, and because that code gets exercised by the entire world, its bugs will be found and removed very quickly.
The source code to the Sun VM is closed source, isn't it? That right there tends to make it less secure. Yes, there are open source VMs out there, but they suffer from other problems including less widespread testing.
I don't know about you, but I'd trust gcc before I'd trust Sun's Java VM.
To be honest and I know this wasn't the original discussion I don't find the performance of the JIT that bad in terms of CPU. For web serving for example a cheapo dell can server serve well over 1.5k req/sec whilst doing some processing each request on a 1.5 JVM in server mode.
First of all, web serving is easy in that you're almost never CPU-limited. Secondly, web servers run for a really long period of time. JIT compliation can approach the theoretical performance of compiled software in the long run. In reality it's not unheard of to actually exceed the performance, because JIT compilation usually employs more dynamic techniques. Yes, in theory you could have self-modifying compiled C-code, but how often do we see that?
The biggest problems I experience with java are startup time and memory usage. Both can be blamed on JIT compilation, I suppose, and the memory problem will tend to lessen over time.
For the server-side I don't mind java that much. For high-performance software I personally prefer vanilla C with essentially no dynamically allocated memory at all, but some people don't find it easy to work in that kind of environment. The bottom line though is that as long as you have a scalable architecture performance is only going to affect the number of machines you have to buy, and machines are usually much cheaper than programmers.
It will be interesting to see what becomes the dominant modern OO, VM based language/platform on Linux.
Hopefully we're going to start moving to an environment where language doesn't particularly matter. If just a small fraction of the work being spent on natural language translation was spent on computer language translation we'd probably already be there.
I was only pointing out that garbage collection can improve speed over explicit allocate/deallocate calls - therefore the fact that java has garbage collection isn't neccessarily a disadvantage in terms of performance.
I'd say it's fairly rare that a well tuned program which explitly allocates and deallocates memory is going to perform better than dynamic garbage collection. In fact, it's pretty much impossible, because there's always going to be some overhead for the garbage collection algorithm itself which isn't useful in the software. Anything you can do in java you can do in assembly better. And anything you can do in assembly you can do in C. You might not want to spend the time programming it in, but it's possible, and 99% of the time you don't have to program it yourself anyway, because the compiler will optimize it for you.
Yes, there's compiled java, but why bother kludging around with a language which was meant to be interpreted if you're going to compile it? What we need is to make smarter compilers - shift the burden of programming on to the machines.
Unless you are comparing essentially the same implementation, the comparison is meaningless.
The fact that no one has come up with a decent java version of any of the software I currently use does lead me to conclusions, though.
I'm all for making a programmer's job easier, but I think the way to do that is with development tools on top of C. In ten years or less it'll probably be a moot point anyway, as there will be tools out there to translate any programming language into any other one anyway.
If I remember right (and I'm not a tax accountant, so go talk to yours), I think that receipts under $75 are no longer required in an audit. I don't know about your company, but in most companies this means that 50%-75% of receipts don't need to be kept.
It's really an issue of materiality. If you're a multi-million dollar software company, then you probably don't need to keep a receipt every time you buy a dozen bagels (although you might have to if you buy a dozen bagels every day). If you're a tiny one-man operation, then maybe you do need to keep records for these expenses (a company which has no evidence for 50-75% of its purchases isn't likely to do well in an audit). Then again, a tiny one-man operation probably isn't going to face an audit in the first place.
If I remember right, Amex will give you copies of everything at year-end that you just stuff in a folder.
Unless it's a cash transaction, the receipt is often superfluous anyway. Even with cash transactions keeping good records is more important than keeping receipts. If your company faces an audit and you hand the auditor a box of receipts, you're probably not going to do very well. On the other hand, if you hand over a file with well kept double-entry books, bank and credit card statements which reconcile to those books, and only a few receipts for some big ticket purchases, you'll probably do fine (unless of course you really were doing something illegal).
It really depends on what you're doing, there are no black and white answers. Record-keeping laws don't require a company to spend millions of dollars recording every penny (a few financial companies like banks aside). The concept is materiality, which has both quantitative and qualitative aspects, and can only truly be determined in the context of the situation.
Users complained about the extra work scanning incoming mail and invoices into the document management system.
What we need is for every office to have a robotic set of hands. But in the mean time, there should really only be one (or a few) manual laborers complaining about scanning in documents. Everyone else should have their documents already scanned in.
Users still printed out paper copies of documents so that they could read them.
I have to admit that this one takes a lot of money to resolve. Dual monitors help a little. Tablet PCs are probably the best, for now.
Despite a fortune spent on consultants auditors picked multiple holes in our system and almost refused to sign over the year-end accounts.
That one seems odd. Most major auditors pretty much *require* data to be submitted in electronic form.
Hard copies allow annotations. Forms do not. Paper can be changed on the fly. Forms can not. Paper is portable. Forms are not.
For internal purposes, most of this could be resolved using tablet PCs. It'd be quite expensive for every employee to have 2 or 3 tablet PCs, but not impossible.
Paper can be folded up, and carried in pockets.
A USB pendrive or whatever they're called can be carried in pockets.
Paper is collaborative. Computers aren't.
You've gotta be joking on this one. Computers have much more potential for collaboration than paper.
Anyone that advocates rigid computer forms over flexible paper, doesn't understand how paper is used in society.
Most people who advocate a "paperless" office don't really mean the elimination of all paper anyway. Electronic data has some definite advantages, and most businesses could benefit from moving a large portion of their paper documents to electronic form.
I work for a CPA firm, and we deal with a lot of paper, though we're moving toward using less of it. We spent an awful lot of time searching through file cabinets, searching within the folders in those file cabinets, and making photocopies of documents to put in those folders. We live in a level 2 flood zone, and should a hurricane hit us much of the paper would likely be ruined. Anyone who advocates not moving toward a paperless office doesn't use very much paper.
I agree that right now paper is expensive to eliminate completely (for internal use, and usually impossible to eliminate completely for external use). I think tablet PCs are a good alternative for many business uses. You can move them around on your desk, and you can write on them. The main problem is that they're so damn expensive. In order to be useful you really need at least two, because a common task is to compare two different documents side by side. Of course with good (and expensive) OCR software, this task tends to go away. Yeah, tablet PCs aren't flexible, but for office use that's not a huge deal.
SSL Client Authentication would stop most phishing attacks. Now the user would have to be dumb enough to download a trojan or send their private key to the attacker.
It's not a man-in-the-middle attack if you trick someone to entering their information into the wrong site.
I knew what he meant, and I'd call it a man-in-the-middle attack too. It's not a technical MITM attack, but a social one. There's the client, the website, and a man-in-the-middle recording the conversation. As was pointed out in this news story, one way to stop this type of attack is to require SSL client authentication.
I would prefer to see technical solutions over legal ones.
What does that mean? People aren't going to adopt technical solutions without an incentive.
Free with every account, you get a credit-card sized, battery powered random number generator. In addition to your password, you have to enter the number displayed on the generator, which changes every thirty seconds.
Great, so the phisher has to steal the money within 30 seconds of you interacting with the website. This won't help very much, if at all.
The bank only lets you access your account from a computer you designate. This could be done through the MAC adress of your NIC, or through a hash function based on your hardware configuration.
Err...How are you supposed to prove you have a particular MAC address? Maybe if Microsoft manages to institute "Trusted Computing" or somesuch it *might* be possible, but even then it's likely to be hacked. And even if it isn't hacked, it'd still be hard to stop a man-in-the-middle attack. See above.
Push the responsibility -- all of it -- for identity theft onto the financial institutions, and phishing will go away.
Isn't the responsibility already on the financial institutions? If someone takes out a loan in your name, do you really think you're required to pay it back?
The victims of "identity theft" are the banks. The consumers only pay in the form of higher fees and interest rates.
it's pretty much unarguable that bestsellers are bad books, box office hits are bad films, the top of the TV ratings list is populated with bad TV shows, and the music that gets to the top of the charts is mostly pretty crap
Ah, yes, anything popular is crap. Now please excuse me while I go off to drink wine, eat cheese, and watch Masterpiece Theatre.
Once a broadcaster starts depending on advertising for revenues, the overriding concern becomes viewer figures, rather than quality of output
Would you say this has happened with PBS? My feeling is that it hasn't, but I'm not completely sure about it.
Ironically, having an overriding concern of viewer figures probably makes more sense if the program is supported by taxes than if it's supported by advertising. If everyone has to pay, then you should try to benefit the most people.
I'd also question your use of "quality". Quality according to whom? Wouldn't the best quality programming also have the most viewers? Or do you think "quality" is an empirical truth to be determined by you?
There's another issue to, and that's with the distribution mechanism. It's not like you can't distribute both a highly viewed, "low quality" show and a less highly viewered, "high quality" show. Yes, you're not going to do this is if the revenues generated by the less popular show don't exceed the costs to create the show, but if that's the case you probably shouldn't be producing that show, no matter how "high quality" you deem it to be.
So, what if I change the date on my computer? What if I download the software from someone else? What if I reverse engineer the softrware to discover the key?
This doesn't sound like a very strong system, regardless of whether or not it's distributed by P2P. I believe on the of the other posters who said his wife works for this company and said that they are only instituting a half-hearted DRM scheme because they're required to do due diligence by the content owners.
He discusses warning signs you should look for in your own work environment that point toward "Getting out".
The company hires an outside consultant who starts interviewing all the workers.
The company asks all its workers to prepare and submit their resumes.
The company institutes a new strict code of conduct and asks everyone to sign it (this makes it easier to fire someone rather than lay them off, thus avoiding paying out unemployment).
Yes, it sounds like it's out of a fiction story, and in fact the first thing happens in the movie Office Space. But all three happened in one of the companies I worked for, before laying off a bunch of people.
If they have software on your system they could, if they wanted, just take that information from you without you even knowing it.
Unless they happen to be an application which continuously uses the internet, they'd have trouble doing this without getting caught by my firewall. And even if they could sneak it past me, it's doubtful that they'd be able to sneak it into the source code in the first place. I use primarily open source software.
You trust them enough to run their software but not enough to submit a bug report?
Pretty much, yes. It's one thing for an employee (or in the case of much of my software, a volunteer) to misuse a core dump. It's another thing altogether for a large group of individuals to intentionally conspire to build a backdoor into software, and to do so without getting caught. Is it possible? Yes, so I try not to keep anything too sensitive on my computer in the first place. But I will try to avoid handing out sensitive personal information to people without a need to know it as much as possible.
If you don't send crash reports then don't bitch that your software crashes.
I don't bitch that my software crashes.
Companies and opensource projects use this information to track severity of bugs and figure out how to fix these bugs.
If a bug bothers me enough I'll diagnose it, describe a way to reproduce it, and submit a bug report. I'm not sending my personal information to some company that I don't even have a written contractual agreement with.
Do you really think that when your PC sends a crash report to Microsoft, Apple, or whomever that there is no chance of some of your files being sent with it?
Does anyone with technical knowhow ever choose to send a crash report to one of those companies? I guess if you're a high-end user on a contract with them, but otherwise it's a pretty crazy thing to do.
Slashdot Mirror
A good JIT is the smarter compiler.
In theory? In a study of the average compiler? In a head to head comparison of the most popular JIT compiler with gcc? What?
Regardless of the performance issues the future of software development is going to be running non-native code on a virtual machine as this has so many advtantages including portability/distribution, security and efficiency of developing large scale systems.
Quite frankly, I don't see these advantages. It's trivial to recompile an app for each platform, and this is the most secure way to do things as well.
Another thing to note is that it was always possible to write more efficient assembler than C, but it was often easier to write more efficient C than assembler due to better code layout, easier management of libraries, code reuse and the manageability of developing larger apps.
You can write assembler in C, and seemlessly switch from one to another (nothing like the kludge of running native code with java). The vast majority of the time you don't need to though because the compiler will create the same machine code as your assembler would anyway. C is largely just a shorthand for assembler. So this is a terrible comparison.
Given that we want the security, stability, portability and other benefits that a virtual machine provides and that the virtual machine runs non-native bytecode and that the JIT is nearly as fast as compiled code and faster in some circumstances - compiling java code to native is pointless from a performance perspective in most practical cases.
Good JIT compilation requires a lot of memory and a significant amount of CPU. I don't see how you can say avoiding that overhead is pointless in all but the most trivial of circumstances.
In fact GCJ compiled java is usually slower than running under a modern JIT.
I don't deny that. Java wasn't meant to be compiled, and good compilers haven't been written for it. That's my whole point.
The reasons for compiling to native is probably more to do with the license restrictions on redistributing the Sun JVM. Due to the licensing restrictions most distros won't contain a full java implementation by default and therefore native comilation and the use of classlibrary may be the only way to conveniently redistribture your java on most linux distros.
Woohoo. Now I see what you mean about the many advantages in portability/distribution, security and efficiency.
In C, it requires almost no thought at all to write insecure code, and to do some things securely requires chunks of wrapper code around most things involving IO layers, wrapper code that is not program logic and can have bugs. In higher-level languages, the user won't be writing that code -- the engineers at Sun will, and because that code gets exercised by the entire world, its bugs will be found and removed very quickly.
The source code to the Sun VM is closed source, isn't it? That right there tends to make it less secure. Yes, there are open source VMs out there, but they suffer from other problems including less widespread testing.
I don't know about you, but I'd trust gcc before I'd trust Sun's Java VM.
To be honest and I know this wasn't the original discussion I don't find the performance of the JIT that bad in terms of CPU. For web serving for example a cheapo dell can server serve well over 1.5k req/sec whilst doing some processing each request on a 1.5 JVM in server mode.
First of all, web serving is easy in that you're almost never CPU-limited. Secondly, web servers run for a really long period of time. JIT compliation can approach the theoretical performance of compiled software in the long run. In reality it's not unheard of to actually exceed the performance, because JIT compilation usually employs more dynamic techniques. Yes, in theory you could have self-modifying compiled C-code, but how often do we see that?
The biggest problems I experience with java are startup time and memory usage. Both can be blamed on JIT compilation, I suppose, and the memory problem will tend to lessen over time.
For the server-side I don't mind java that much. For high-performance software I personally prefer vanilla C with essentially no dynamically allocated memory at all, but some people don't find it easy to work in that kind of environment. The bottom line though is that as long as you have a scalable architecture performance is only going to affect the number of machines you have to buy, and machines are usually much cheaper than programmers.
It will be interesting to see what becomes the dominant modern OO, VM based language/platform on Linux.
Hopefully we're going to start moving to an environment where language doesn't particularly matter. If just a small fraction of the work being spent on natural language translation was spent on computer language translation we'd probably already be there.
I was only pointing out that garbage collection can improve speed over explicit allocate/deallocate calls - therefore the fact that java has garbage collection isn't neccessarily a disadvantage in terms of performance.
I'd say it's fairly rare that a well tuned program which explitly allocates and deallocates memory is going to perform better than dynamic garbage collection. In fact, it's pretty much impossible, because there's always going to be some overhead for the garbage collection algorithm itself which isn't useful in the software. Anything you can do in java you can do in assembly better. And anything you can do in assembly you can do in C. You might not want to spend the time programming it in, but it's possible, and 99% of the time you don't have to program it yourself anyway, because the compiler will optimize it for you.
Yes, there's compiled java, but why bother kludging around with a language which was meant to be interpreted if you're going to compile it? What we need is to make smarter compilers - shift the burden of programming on to the machines.
And we all know they don't have any garbage collection libraries for C/C++.
Most developers shouldn't be thinking about this stuff though.
Correct, but at least one developer on each programming team should be.
Unless you are comparing essentially the same implementation, the comparison is meaningless.
The fact that no one has come up with a decent java version of any of the software I currently use does lead me to conclusions, though.
I'm all for making a programmer's job easier, but I think the way to do that is with development tools on top of C. In ten years or less it'll probably be a moot point anyway, as there will be tools out there to translate any programming language into any other one anyway.
Question: would you prefer to hire a "mediocre java programmer", for this position, or "a mediocre C++ programmer"?
Answer: no.
If I remember right (and I'm not a tax accountant, so go talk to yours), I think that receipts under $75 are no longer required in an audit. I don't know about your company, but in most companies this means that 50%-75% of receipts don't need to be kept.
It's really an issue of materiality. If you're a multi-million dollar software company, then you probably don't need to keep a receipt every time you buy a dozen bagels (although you might have to if you buy a dozen bagels every day). If you're a tiny one-man operation, then maybe you do need to keep records for these expenses (a company which has no evidence for 50-75% of its purchases isn't likely to do well in an audit). Then again, a tiny one-man operation probably isn't going to face an audit in the first place.
If I remember right, Amex will give you copies of everything at year-end that you just stuff in a folder.
Unless it's a cash transaction, the receipt is often superfluous anyway. Even with cash transactions keeping good records is more important than keeping receipts. If your company faces an audit and you hand the auditor a box of receipts, you're probably not going to do very well. On the other hand, if you hand over a file with well kept double-entry books, bank and credit card statements which reconcile to those books, and only a few receipts for some big ticket purchases, you'll probably do fine (unless of course you really were doing something illegal).
It really depends on what you're doing, there are no black and white answers. Record-keeping laws don't require a company to spend millions of dollars recording every penny (a few financial companies like banks aside). The concept is materiality, which has both quantitative and qualitative aspects, and can only truly be determined in the context of the situation.
Users complained about the extra work scanning incoming mail and invoices into the document management system.
What we need is for every office to have a robotic set of hands. But in the mean time, there should really only be one (or a few) manual laborers complaining about scanning in documents. Everyone else should have their documents already scanned in.
Users still printed out paper copies of documents so that they could read them.
I have to admit that this one takes a lot of money to resolve. Dual monitors help a little. Tablet PCs are probably the best, for now.
Despite a fortune spent on consultants auditors picked multiple holes in our system and almost refused to sign over the year-end accounts.
That one seems odd. Most major auditors pretty much *require* data to be submitted in electronic form.
Hard copies allow annotations. Forms do not. Paper can be changed on the fly. Forms can not. Paper is portable. Forms are not.
For internal purposes, most of this could be resolved using tablet PCs. It'd be quite expensive for every employee to have 2 or 3 tablet PCs, but not impossible.
Paper can be folded up, and carried in pockets.
A USB pendrive or whatever they're called can be carried in pockets.
Paper is collaborative. Computers aren't.
You've gotta be joking on this one. Computers have much more potential for collaboration than paper.
Anyone that advocates rigid computer forms over flexible paper, doesn't understand how paper is used in society.
Most people who advocate a "paperless" office don't really mean the elimination of all paper anyway. Electronic data has some definite advantages, and most businesses could benefit from moving a large portion of their paper documents to electronic form.
I work for a CPA firm, and we deal with a lot of paper, though we're moving toward using less of it. We spent an awful lot of time searching through file cabinets, searching within the folders in those file cabinets, and making photocopies of documents to put in those folders. We live in a level 2 flood zone, and should a hurricane hit us much of the paper would likely be ruined. Anyone who advocates not moving toward a paperless office doesn't use very much paper.
I agree that right now paper is expensive to eliminate completely (for internal use, and usually impossible to eliminate completely for external use). I think tablet PCs are a good alternative for many business uses. You can move them around on your desk, and you can write on them. The main problem is that they're so damn expensive. In order to be useful you really need at least two, because a common task is to compare two different documents side by side. Of course with good (and expensive) OCR software, this task tends to go away. Yeah, tablet PCs aren't flexible, but for office use that's not a huge deal.
Stopping phishing requires a different approach.
SSL Client Authentication would stop most phishing attacks. Now the user would have to be dumb enough to download a trojan or send their private key to the attacker.
It's not a man-in-the-middle attack if you trick someone to entering their information into the wrong site.
I knew what he meant, and I'd call it a man-in-the-middle attack too. It's not a technical MITM attack, but a social one. There's the client, the website, and a man-in-the-middle recording the conversation. As was pointed out in this news story, one way to stop this type of attack is to require SSL client authentication.
#4, obtain a security certificate from one of the default CAs saying that you're paypal. That one's probably the tough one.
I would prefer to see technical solutions over legal ones.
What does that mean? People aren't going to adopt technical solutions without an incentive.
Free with every account, you get a credit-card sized, battery powered random number generator. In addition to your password, you have to enter the number displayed on the generator, which changes every thirty seconds.
Great, so the phisher has to steal the money within 30 seconds of you interacting with the website. This won't help very much, if at all.
The bank only lets you access your account from a computer you designate. This could be done through the MAC adress of your NIC, or through a hash function based on your hardware configuration.
Err...How are you supposed to prove you have a particular MAC address? Maybe if Microsoft manages to institute "Trusted Computing" or somesuch it *might* be possible, but even then it's likely to be hacked. And even if it isn't hacked, it'd still be hard to stop a man-in-the-middle attack. See above.
Push the responsibility -- all of it -- for identity theft onto the financial institutions, and phishing will go away.
Isn't the responsibility already on the financial institutions? If someone takes out a loan in your name, do you really think you're required to pay it back?
The victims of "identity theft" are the banks. The consumers only pay in the form of higher fees and interest rates.
it's pretty much unarguable that bestsellers are bad books, box office hits are bad films, the top of the TV ratings list is populated with bad TV shows, and the music that gets to the top of the charts is mostly pretty crap
Ah, yes, anything popular is crap. Now please excuse me while I go off to drink wine, eat cheese, and watch Masterpiece Theatre.
No, sarcasm.
Once a broadcaster starts depending on advertising for revenues, the overriding concern becomes viewer figures, rather than quality of output
Would you say this has happened with PBS? My feeling is that it hasn't, but I'm not completely sure about it.
Ironically, having an overriding concern of viewer figures probably makes more sense if the program is supported by taxes than if it's supported by advertising. If everyone has to pay, then you should try to benefit the most people.
I'd also question your use of "quality". Quality according to whom? Wouldn't the best quality programming also have the most viewers? Or do you think "quality" is an empirical truth to be determined by you?
There's another issue to, and that's with the distribution mechanism. It's not like you can't distribute both a highly viewed, "low quality" show and a less highly viewered, "high quality" show. Yes, you're not going to do this is if the revenues generated by the less popular show don't exceed the costs to create the show, but if that's the case you probably shouldn't be producing that show, no matter how "high quality" you deem it to be.
So, what if I change the date on my computer? What if I download the software from someone else? What if I reverse engineer the softrware to discover the key?
This doesn't sound like a very strong system, regardless of whether or not it's distributed by P2P. I believe on the of the other posters who said his wife works for this company and said that they are only instituting a half-hearted DRM scheme because they're required to do due diligence by the content owners.
So, to all you experienced developers, which are the top software development magazines?
Definitely Slashdot, you should subscribe to them immediately. Quality journalism by a professional company. Well worth it.
He discusses warning signs you should look for in your own work environment that point toward "Getting out".
Yes, it sounds like it's out of a fiction story, and in fact the first thing happens in the movie Office Space. But all three happened in one of the companies I worked for, before laying off a bunch of people.
If they have software on your system they could, if they wanted, just take that information from you without you even knowing it.
Unless they happen to be an application which continuously uses the internet, they'd have trouble doing this without getting caught by my firewall. And even if they could sneak it past me, it's doubtful that they'd be able to sneak it into the source code in the first place. I use primarily open source software.
You trust them enough to run their software but not enough to submit a bug report?
Pretty much, yes. It's one thing for an employee (or in the case of much of my software, a volunteer) to misuse a core dump. It's another thing altogether for a large group of individuals to intentionally conspire to build a backdoor into software, and to do so without getting caught. Is it possible? Yes, so I try not to keep anything too sensitive on my computer in the first place. But I will try to avoid handing out sensitive personal information to people without a need to know it as much as possible.
If you don't send crash reports then don't bitch that your software crashes.
I don't bitch that my software crashes.
Companies and opensource projects use this information to track severity of bugs and figure out how to fix these bugs.
If a bug bothers me enough I'll diagnose it, describe a way to reproduce it, and submit a bug report. I'm not sending my personal information to some company that I don't even have a written contractual agreement with.
Do you really think that when your PC sends a crash report to Microsoft, Apple, or whomever that there is no chance of some of your files being sent with it?
Does anyone with technical knowhow ever choose to send a crash report to one of those companies? I guess if you're a high-end user on a contract with them, but otherwise it's a pretty crazy thing to do.