Right, so if the long term goal is to run these trains at close to 900kph, and something has gone wrong badly enough that they crash in the first place given the design, it's going to be some sort of catastrophic failure.
I'm not sure how anyone finds this "joke" funny. If one of these things crashes at full speed, it is unlikely that anyone survives, and you are looking at more fatalities than flying a passenger aircraft into the WTC on 9/11.
yeah, it's called "public investment", each person pays a little bit so that everyone can use the thing, think "public roads"
Unfortunately, a real and serious difficulty with high-speed rail is that each person doesn't pay a little bit, they pay a small fortune, while in practice only a relatively small number of people will ever benefit directly from the faster travel times.
It's not a simple thing to consider, because of course others might benefit indirectly.
On the other hand, other others will be worse off. Again, some of this is direct: building the new HS2 high speed line from London up to major cities in the north of England via Birmingham is going to cause a lot of disruption to some people. In some cases, it will wipe out entire small communities, because going around them was deemed too expensive. It's all fun and games until it's your family home or established place of business that gets a Compulsory Purchase Order.
And again, there will be indirect negative consequences as well. For example, building HS2 might actually harm our local economy here in Cambridge, because to some extent there is only finite investment capital to go around, and by not being near the new line, our area becomes a less attractive place to make some of those investments.
But the biggest elephant in the room is the opportunity cost. These kinds of projects commit almost unimaginable amounts of public money -- money collected from a whole generation of taxpayers over several years -- to one single project with limited benefits. You can't just consider high speed rail in isolation. You have to also consider the benefits you don't now receive from, say, upgrading existing rail infrastructure or expanding the road network, both of which potentially reduce journey times significantly for a lot more people and increase freight capacity. And of course taxpayers' money also gets spent in areas outside of transport, like running hospitals and educating kids, where there are always considerable pressures and plenty of ways more money could help. You could even do something crazy like not taking that hard-earned money from taxpayers in the first place and instead letting them spend it on things they valued, thus boosting the economy in whatever areas those happen to be.
Basically, high speed rail sounds great until you check the details, but it is far from being a clear win economically, environmentally or politically when you actually look at the details. Time will tell whether the HS2 project in the UK lives up to the hype, but "it's public investment" is a long way from a robust argument in this particular case. And just about everything here goes double for the very high speed technologies we're talking about in this article.
Also, serious info for serious Slashdotters here . . . the Chancellor of Germany, Angela Merkel, has a PhD in Physics. Can any other country boast a top political leader who has a STEM leader . . . ?
Not the leader of our government, but my local MP in the England is one of the very few current ones who has a science-related PhD.
Other MPs have openly mocked him in Parliament at various times for doing things like talking intelligently, raising valid concerns about something, or making arguments based on dumb stuff like facts and evidence.
Whether or not anyone agrees with this MP's political views, it's a pretty poor reflection on the calibre of colleagues he has to "debate" with.
She has a tough job . . . a scientist turned politician! But that is the message here . . . it is not about technology, but politics.
But the effect of doing so might make reviews less valuable. Some games might take far more than 2 hours to really get in to, while others might get worse after 2 hours by virtue of being too repetitive. Or, in the case of this game, you might not run into bugs in 2 hours.
So the only credible reviews will generally be of the form "it sucks" or of the form "we don't know yet".
Good luck getting your launch day hype up when those are your options, publishers.
Why should we upgrade when we don't really have to?
Because if they don't, someone else will. That's why you also need laws to block local communities from arranging their own local services, you see.
I'm not normally a huge supporter of the world of corporate politics, but in this case, I hope the likes of Google call their bluff and cost them a staggering amount of money.
Call me back when Smart TV's are pre-configured to connect automatically to cell networks. Then we can talk.
I called that one as the big risk a long time ago. As long as you can just not connect a potentially intrusive device to your Internet connection, you always have a certain degree of protection if you want it. As soon as devices can make their own connections, either you live in a Faraday cage or you're permanently at risk if you have any untrusted device nearby.
The disturbing thing is that it won't even need relative expensive access to a cell network before long, because everything from shared WiFi networks (think BT Openzone, for those in the UK) to mesh networks (a distributed, peer-to-peer wireless communications system) via drones is potentially a threat in this context.
The only way to stop this is going to be legislation requiring sufficient disclosure and/or outright prohibiting certain behaviours that are too widely abused, with meaningful penalties for infringement (i.e., criminal sanctions that will pierce corporate veils and throw executives in jail).
Don't like the "smart tv" features? Don't fucking buy one.
That argument is worth about as much as "nothing to hide, nothing to fear" once you reach the point where some undesirable item or behaviour is theoretically not compulsory but is necessary to live a normal life as part of society.
Don't like abusive airport security? Don't ever go on holiday to intersting faraway places or fly across a large country to see your family.
Don't like Facebook data mining your life? Don't participate in what is currently the main mode of group organisation for a lot of social groups.
Don't like unknown parties tracking your movements via your cell phone? Don't use the most common form of direct communication in today's society.
Don't like unknown parties tracking what you access and search for on-line? Don't use the greatest information and education resource created in the history of humanity.
At some point, something is de facto required to live a normal life, even if there is some weasel-worded get-out clause where it isn't strictly necessary so, y'know, no need for pesky things like basic human rights and common decency in how we treat each other.
Delaying a flight over this shows how much technical ineptitude is there.
It also shows, however unfortunately, the futility of trying to protect everyone against everything all the time. Who needs to blow themselves up, or even risk the explicit criminal sanctions you'd face for making a bomb threat, when you can just co-opt some unwitting and otherwise innocent traveller's personal device somewhere outside a travel hub or other likely target for an attack?
If our threshold for fear has become so low that some kid's not-so-funny practical joke can now result in several hours of delays to long distance transportation, then apparently in a very literal sense the terrorists have already succeeded. Next you'll be telling me we spend time and money prosecuting angry travellers over tweets sent in frustration when airports are closed.
Yes, in a sense I am too lazy to compile it. I have several businesses to run, family commitments, and so on. That leaves limited time for helping with volunteer efforts, and I choose to spend it helping projects where I can make what seems like the most valuable contribution in that time.
Sometimes that includes doing things for FOSS projects, but right now Mozilla's projects are not among them. The point is that they might have been if they had a better build process on Windows and/or better documentation about that process. While I probably have been relatively busy in recent years, somehow I doubt I'm the only potential contributor who has been deterred by the barriers to getting started. Writing illiterate, profanity-laden posts at me on Slashdot isn't going to help anyone, but improving the situation I've highlighted might.
I use VMs all the time, but they won't solve this particular problem for most people. Please read the other posts before you reply, as we've already covered this elsewhere in the thread.
FWIW, I agree with almost everything you wrote. I have nothing against coverage tools, and I use them occasionally myself. I just think it's important to have a realistic view of the benefits you do and don't receive.
The only thing I disagree with is your final paragraph, where you talk about safety-critical code. If you really were working on systems where a failure would have catastrophic consequences, I would hope you had a QA process a lot more sophisticated than running a test suite and this kind of coverage tool to check for problems! This is precisely because coverage tools don't really provide solid evidence about what has been tested. Like an automated unit test suite, they only provide a rough guide, which can certainly be useful but is far from a robust guarantee of anything.
I would therefore argue that these tools are much more applicable, in the real world, to projects that are not safety critical. Most projects can't accept the overheads that are reasonable for those more demanding environments, but the developers might still want to do the best they can under the more usual time pressures and resource constraints for commercial or FOSS projects.
No doubt it is possible set it all up and get it working eventually. I've worked on projects with much more complicated set-ups than what you describe that build on a lot more different platforms than Firefox, and once you've figured out the details things generally run OK.
That said, there are quite a few statements even on the page you linked to (which is also the one I'd read last time I looked into this) that suggest requirements and dependencies beyond a single PATH update. An obvious example is that prohibiting spaces in the path to the source directory means some people won't be able to work in the standard user data directory on their Windows system, and installing outside that directory might mean more work to configure back-ups, anti-virus (not scanning build outputs to avoid killing performance), and so on.
The problem here is not what is possible, just the time and risk required to get there. This isn't helped IMHO by the lack of transparency in Mozilla's documentation for contributors; I'm all for having a systematic, one-stop tool like MozillaBuild to automate the process, but you still have to explain what that process is so the developer knows what MozillaBuild is going to do to their system.
If someone wants to become a regular contributor and doesn't have a lot of other constraints on their development PC, all of this might not be a big deal, but if every OSS project came with the same barrier to entry, the OSS world would fall apart tomorrow.
Fair enough. I would agree that the strategy you're describing could be an option in a software development shop where volume licensing is routine, and that given that ability it could well make sense to set up different standardised VMs for working on different projects.
Unfortunately, the average developer who might contribute to Firefox in their spare time isn't likely to have those kinds of professional-grade agreements in place for their own private projects, so I still don't think VMs are a general solution to the original problem that an onerous build system might discourage contributions from otherwise willing volunteers.
If it were just one little thing like a path that needed to be customised, obviously it would be trivial to do so. Unfortunately, with the kind of project that has a whole custom build system and wants its exact required version of everything under the sun installed, it is rarely so simple. For example, the consequences of having two different versions of a VCS installed on your system could be horrible if there had been a change in the internal source repository representation from one to the other and you somehow wound up running the wrong one even once.
All that code coverage does is let you focus on what has not been touched, then you'll be able to test it somehow.
The trouble is that what you really need to test isn't how much coverage of the code you've got, but how much coverage of the possible input space. More specifically, you ideally want to know that each distinct combination of inputs that will cause a different type of behaviour in the code has been considered.
Of course, this is typically an implausibly difficult problem to solve in real world projects. To see why, consider that this article proudly claimed that finding the special case of clearing 4 lines together twice in a row was easy with their tool, and it also said that there were similar combo special cases for 3, 2 or 1 lines, but it conveniently overlooked the possibility of code that ran in all four cases and took the number of lines as a parameter. Testing for any one of those four cases would count as coverage with most tools, but wouldn't guard against implicit conditionals like overflow/underflow that might be relevant to some cases but not others, nor for behaviours that arose only with certain combinations of multiple explicit conditions.
Coverage tools are useful up to a point, but not nearly the silver bullets that these kinds of article suggest.
It's your fault for using Windows, the platform where building cross-platform software is always black magic.
Yes, silly me, using the same platform for building and testing as approximately 100% of my customers do.
Sadly, the platforms that we geeks like to use aren't particularly relevant to a discussion about software for a mainstream audience, because that mainstream audience isn't running Linux and most of it isn't running OS X either.
I'm well aware of the advantages of using VMs for creating a controlled environment. Unfortunately, that doesn't make my previous observations about licensing any less true.
I don't know what you mean by "development only licensing options" as far as Windows is concerned. There are different rules if you use Software Assurance to sort out your licensing, but that's the only exception to the one VM/one licensed copy rule as far as I'm aware. If you know better, please cite accordingly, as I'm sure plenty of us would like to hear about it.
Unfortunately, in this case that '????' is something like "develop several years' worth of cross-compilation infrastructure so you can build on your guest OS but run on the host".
Maybe, but unless you condone software piracy, that would require either buying a second Windows licence (unless you have one of the SA schemes that covers using Windows as both host and guest OS) or running something like Linux as your guest OS and figuring out the cross-compilation issues (if that's possible).
With today's software and licensing landscape, I just don't think setting up a custom VM for every project you work on is viable, nor that imposing burdens on that kind of level is the way to encourage skilled but casual/irregular contributors to help your project.
Unfortunately, like too many OSS projects, Mozilla seems to think it will have the only cygwin instance on my system. It therefore assumes it's OK for me to just reconfigure the entire universe according to its preferences, redefine all my paths so the MozillaBuild version of everything takes precedence over anything else that's already installed, and so on.
In reality, I have various other tools installed that bridge the Windows and Linux worlds, including things fundamental to using various version control systems and other everyday needs. As much as I'd like to support Mozilla and be willing to contribute a bit here and there, I'm not going to compromise the development machine I also use to earn my pay cheque just to get their esoteric build system to work.
Estimates of civilian casualties from the 2003 Iraq War and its aftermath vary significantly, but many are of the same order of magnitude as the deaths caused at Hiroshima and Nagasaki when the nuclear weapons were used.
I'm not sure modern warfare is as good at avoiding collateral damage as you seem to be suggesting. The causes of those civilian deaths might not be the same mechanically, but it's no less a tragedy if an innocent person dies as a side effect of some military action rather than directly by taking a bullet.
Slashdot Mirror
Right, so if the long term goal is to run these trains at close to 900kph, and something has gone wrong badly enough that they crash in the first place given the design, it's going to be some sort of catastrophic failure.
I'm not sure how anyone finds this "joke" funny. If one of these things crashes at full speed, it is unlikely that anyone survives, and you are looking at more fatalities than flying a passenger aircraft into the WTC on 9/11.
yeah, it's called "public investment", each person pays a little bit so that everyone can use the thing, think "public roads"
Unfortunately, a real and serious difficulty with high-speed rail is that each person doesn't pay a little bit, they pay a small fortune, while in practice only a relatively small number of people will ever benefit directly from the faster travel times.
It's not a simple thing to consider, because of course others might benefit indirectly.
On the other hand, other others will be worse off. Again, some of this is direct: building the new HS2 high speed line from London up to major cities in the north of England via Birmingham is going to cause a lot of disruption to some people. In some cases, it will wipe out entire small communities, because going around them was deemed too expensive. It's all fun and games until it's your family home or established place of business that gets a Compulsory Purchase Order.
And again, there will be indirect negative consequences as well. For example, building HS2 might actually harm our local economy here in Cambridge, because to some extent there is only finite investment capital to go around, and by not being near the new line, our area becomes a less attractive place to make some of those investments.
But the biggest elephant in the room is the opportunity cost. These kinds of projects commit almost unimaginable amounts of public money -- money collected from a whole generation of taxpayers over several years -- to one single project with limited benefits. You can't just consider high speed rail in isolation. You have to also consider the benefits you don't now receive from, say, upgrading existing rail infrastructure or expanding the road network, both of which potentially reduce journey times significantly for a lot more people and increase freight capacity. And of course taxpayers' money also gets spent in areas outside of transport, like running hospitals and educating kids, where there are always considerable pressures and plenty of ways more money could help. You could even do something crazy like not taking that hard-earned money from taxpayers in the first place and instead letting them spend it on things they valued, thus boosting the economy in whatever areas those happen to be.
Basically, high speed rail sounds great until you check the details, but it is far from being a clear win economically, environmentally or politically when you actually look at the details. Time will tell whether the HS2 project in the UK lives up to the hype, but "it's public investment" is a long way from a robust argument in this particular case. And just about everything here goes double for the very high speed technologies we're talking about in this article.
Also, serious info for serious Slashdotters here . . . the Chancellor of Germany, Angela Merkel, has a PhD in Physics. Can any other country boast a top political leader who has a STEM leader . . . ?
Not the leader of our government, but my local MP in the England is one of the very few current ones who has a science-related PhD.
Other MPs have openly mocked him in Parliament at various times for doing things like talking intelligently, raising valid concerns about something, or making arguments based on dumb stuff like facts and evidence.
Whether or not anyone agrees with this MP's political views, it's a pretty poor reflection on the calibre of colleagues he has to "debate" with.
She has a tough job . . . a scientist turned politician! But that is the message here . . . it is not about technology, but politics.
Sad, but apparently true.
But the effect of doing so might make reviews less valuable. Some games might take far more than 2 hours to really get in to, while others might get worse after 2 hours by virtue of being too repetitive. Or, in the case of this game, you might not run into bugs in 2 hours.
So the only credible reviews will generally be of the form "it sucks" or of the form "we don't know yet".
Good luck getting your launch day hype up when those are your options, publishers.
This is a joke, right?
Um... Yes. I kinda figured that was obvious from next sentence. Oh well.
Why should we upgrade when we don't really have to?
Because if they don't, someone else will. That's why you also need laws to block local communities from arranging their own local services, you see.
I'm not normally a huge supporter of the world of corporate politics, but in this case, I hope the likes of Google call their bluff and cost them a staggering amount of money.
Call me back when Smart TV's are pre-configured to connect automatically to cell networks. Then we can talk.
I called that one as the big risk a long time ago. As long as you can just not connect a potentially intrusive device to your Internet connection, you always have a certain degree of protection if you want it. As soon as devices can make their own connections, either you live in a Faraday cage or you're permanently at risk if you have any untrusted device nearby.
The disturbing thing is that it won't even need relative expensive access to a cell network before long, because everything from shared WiFi networks (think BT Openzone, for those in the UK) to mesh networks (a distributed, peer-to-peer wireless communications system) via drones is potentially a threat in this context.
The only way to stop this is going to be legislation requiring sufficient disclosure and/or outright prohibiting certain behaviours that are too widely abused, with meaningful penalties for infringement (i.e., criminal sanctions that will pierce corporate veils and throw executives in jail).
It's a smart tv. You wouldn't have one if you weren't going to connect it to the internet.
Until you can't buy any form of TV that isn't a so-called smart TV and/or broadcast TV completely gives way to on-demand real-time downloads.
Don't like the "smart tv" features? Don't fucking buy one.
That argument is worth about as much as "nothing to hide, nothing to fear" once you reach the point where some undesirable item or behaviour is theoretically not compulsory but is necessary to live a normal life as part of society.
Don't like abusive airport security? Don't ever go on holiday to intersting faraway places or fly across a large country to see your family.
Don't like Facebook data mining your life? Don't participate in what is currently the main mode of group organisation for a lot of social groups.
Don't like unknown parties tracking your movements via your cell phone? Don't use the most common form of direct communication in today's society.
Don't like unknown parties tracking what you access and search for on-line? Don't use the greatest information and education resource created in the history of humanity.
At some point, something is de facto required to live a normal life, even if there is some weasel-worded get-out clause where it isn't strictly necessary so, y'know, no need for pesky things like basic human rights and common decency in how we treat each other.
Delaying a flight over this shows how much technical ineptitude is there.
It also shows, however unfortunately, the futility of trying to protect everyone against everything all the time. Who needs to blow themselves up, or even risk the explicit criminal sanctions you'd face for making a bomb threat, when you can just co-opt some unwitting and otherwise innocent traveller's personal device somewhere outside a travel hub or other likely target for an attack?
If our threshold for fear has become so low that some kid's not-so-funny practical joke can now result in several hours of delays to long distance transportation, then apparently in a very literal sense the terrorists have already succeeded. Next you'll be telling me we spend time and money prosecuting angry travellers over tweets sent in frustration when airports are closed.
Yes, in a sense I am too lazy to compile it. I have several businesses to run, family commitments, and so on. That leaves limited time for helping with volunteer efforts, and I choose to spend it helping projects where I can make what seems like the most valuable contribution in that time.
Sometimes that includes doing things for FOSS projects, but right now Mozilla's projects are not among them. The point is that they might have been if they had a better build process on Windows and/or better documentation about that process. While I probably have been relatively busy in recent years, somehow I doubt I'm the only potential contributor who has been deterred by the barriers to getting started. Writing illiterate, profanity-laden posts at me on Slashdot isn't going to help anyone, but improving the situation I've highlighted might.
I use VMs all the time, but they won't solve this particular problem for most people. Please read the other posts before you reply, as we've already covered this elsewhere in the thread.
FWIW, I agree with almost everything you wrote. I have nothing against coverage tools, and I use them occasionally myself. I just think it's important to have a realistic view of the benefits you do and don't receive.
The only thing I disagree with is your final paragraph, where you talk about safety-critical code. If you really were working on systems where a failure would have catastrophic consequences, I would hope you had a QA process a lot more sophisticated than running a test suite and this kind of coverage tool to check for problems! This is precisely because coverage tools don't really provide solid evidence about what has been tested. Like an automated unit test suite, they only provide a rough guide, which can certainly be useful but is far from a robust guarantee of anything.
I would therefore argue that these tools are much more applicable, in the real world, to projects that are not safety critical. Most projects can't accept the overheads that are reasonable for those more demanding environments, but the developers might still want to do the best they can under the more usual time pressures and resource constraints for commercial or FOSS projects.
No doubt it is possible set it all up and get it working eventually. I've worked on projects with much more complicated set-ups than what you describe that build on a lot more different platforms than Firefox, and once you've figured out the details things generally run OK.
That said, there are quite a few statements even on the page you linked to (which is also the one I'd read last time I looked into this) that suggest requirements and dependencies beyond a single PATH update. An obvious example is that prohibiting spaces in the path to the source directory means some people won't be able to work in the standard user data directory on their Windows system, and installing outside that directory might mean more work to configure back-ups, anti-virus (not scanning build outputs to avoid killing performance), and so on.
The problem here is not what is possible, just the time and risk required to get there. This isn't helped IMHO by the lack of transparency in Mozilla's documentation for contributors; I'm all for having a systematic, one-stop tool like MozillaBuild to automate the process, but you still have to explain what that process is so the developer knows what MozillaBuild is going to do to their system.
If someone wants to become a regular contributor and doesn't have a lot of other constraints on their development PC, all of this might not be a big deal, but if every OSS project came with the same barrier to entry, the OSS world would fall apart tomorrow.
Fair enough. I would agree that the strategy you're describing could be an option in a software development shop where volume licensing is routine, and that given that ability it could well make sense to set up different standardised VMs for working on different projects.
Unfortunately, the average developer who might contribute to Firefox in their spare time isn't likely to have those kinds of professional-grade agreements in place for their own private projects, so I still don't think VMs are a general solution to the original problem that an onerous build system might discourage contributions from otherwise willing volunteers.
If it were just one little thing like a path that needed to be customised, obviously it would be trivial to do so. Unfortunately, with the kind of project that has a whole custom build system and wants its exact required version of everything under the sun installed, it is rarely so simple. For example, the consequences of having two different versions of a VCS installed on your system could be horrible if there had been a change in the internal source repository representation from one to the other and you somehow wound up running the wrong one even once.
All that code coverage does is let you focus on what has not been touched, then you'll be able to test it somehow.
The trouble is that what you really need to test isn't how much coverage of the code you've got, but how much coverage of the possible input space. More specifically, you ideally want to know that each distinct combination of inputs that will cause a different type of behaviour in the code has been considered.
Of course, this is typically an implausibly difficult problem to solve in real world projects. To see why, consider that this article proudly claimed that finding the special case of clearing 4 lines together twice in a row was easy with their tool, and it also said that there were similar combo special cases for 3, 2 or 1 lines, but it conveniently overlooked the possibility of code that ran in all four cases and took the number of lines as a parameter. Testing for any one of those four cases would count as coverage with most tools, but wouldn't guard against implicit conditionals like overflow/underflow that might be relevant to some cases but not others, nor for behaviours that arose only with certain combinations of multiple explicit conditions.
Coverage tools are useful up to a point, but not nearly the silver bullets that these kinds of article suggest.
It's your fault for using Windows, the platform where building cross-platform software is always black magic.
Yes, silly me, using the same platform for building and testing as approximately 100% of my customers do.
Sadly, the platforms that we geeks like to use aren't particularly relevant to a discussion about software for a mainstream audience, because that mainstream audience isn't running Linux and most of it isn't running OS X either.
I'm well aware of the advantages of using VMs for creating a controlled environment. Unfortunately, that doesn't make my previous observations about licensing any less true.
I don't know what you mean by "development only licensing options" as far as Windows is concerned. There are different rules if you use Software Assurance to sort out your licensing, but that's the only exception to the one VM/one licensed copy rule as far as I'm aware. If you know better, please cite accordingly, as I'm sure plenty of us would like to hear about it.
Unfortunately, in this case that '????' is something like "develop several years' worth of cross-compilation infrastructure so you can build on your guest OS but run on the host".
Maybe, but unless you condone software piracy, that would require either buying a second Windows licence (unless you have one of the SA schemes that covers using Windows as both host and guest OS) or running something like Linux as your guest OS and figuring out the cross-compilation issues (if that's possible).
With today's software and licensing landscape, I just don't think setting up a custom VM for every project you work on is viable, nor that imposing burdens on that kind of level is the way to encourage skilled but casual/irregular contributors to help your project.
Unfortunately, like too many OSS projects, Mozilla seems to think it will have the only cygwin instance on my system. It therefore assumes it's OK for me to just reconfigure the entire universe according to its preferences, redefine all my paths so the MozillaBuild version of everything takes precedence over anything else that's already installed, and so on.
In reality, I have various other tools installed that bridge the Windows and Linux worlds, including things fundamental to using various version control systems and other everyday needs. As much as I'd like to support Mozilla and be willing to contribute a bit here and there, I'm not going to compromise the development machine I also use to earn my pay cheque just to get their esoteric build system to work.
The system cannot find the path specified.
I guess those of us using Windows still aren't going to be contributing much any time soon. :-(
Estimates of civilian casualties from the 2003 Iraq War and its aftermath vary significantly, but many are of the same order of magnitude as the deaths caused at Hiroshima and Nagasaki when the nuclear weapons were used.
I'm not sure modern warfare is as good at avoiding collateral damage as you seem to be suggesting. The causes of those civilian deaths might not be the same mechanically, but it's no less a tragedy if an innocent person dies as a side effect of some military action rather than directly by taking a bullet.