1) You want to support phones that were manufactured in 2004? How many of them will be still functional in 2010?
2) The first App Store, Apple's, wasn't open until 2008 so how could its existence be a deciding factor in 2005?
3) Do all 2.1 Android apps work unmodified on 1.6 handsets? Will iOS 4 support 1st gen iPhones?
I think your analogy is not accurate because:
- Nokia said that all future *n-series* devices would not run Symbian^3. Thus c-series, e-series and x-series are getting Symbian^3 in the future. N-series is a small part of Nokia's sales.
- Nokia *is* developing a next version of Symbian, which is not Meego (that replaces Maemo), but Symbian^4. A few days ago they confirmed that future n-series devices will get Symbian^4 too (and it's not vapourware, since anybody can follow Symbian^4 development on symbian.org).
Yes, but the Nuron is a crippled version of the 5230, which in its turn is already a cheap phone. If this is the best Nokia offers in the USA, then I begin to understand why Nokia has such a thin market share there.
You could have bought a 5800, it would have costed you less than half the money as the N97, and still have more features than any remotely comparable phone in that price range. Nokia flagships are very overpriced, they've always been, because apparently there are people who buy them anyways. Perhaps the N97 debacle will change things, and in fact it looks like the N8 will be quite affordable.
I'm not saying what you say is not true, but you have to update your points to 2010.
- Treating the app developer as some annoyance to be fobbed off whenever possible. No idea what's it's like now, but back in the day, to develop an app for Symbian you have to splash out on a compiler which retailed at over $2k. And if god forbid you wanted to actually debug code running on your device (rather than the not particularly good emulator), well, then you need a HW debugger box which ran to another $2k
Yes, but the compiler has now been free for years, and in particular has been free since *before* the iPhone and Android existed. So if you really were interested in a fair comparison, you would compare Symbian with the alternatives of the time. Today Symbian is fully free, as in speech - you can hg clone the whole OS.
- Completely and comprehensively fragmenting the eco-system whenever the slightest opportunity to do so arose. Hence Symbian never really existed as a platform per se - it was all an obscure and vast ecosytem of devices each with its own configuration - hence the prolliferation of Series 40, 60, 70, UIQ etc etc.
Series 40 was never Symbian-based, so you're just trolling here. Series 70 never existed. Moreover, everything different than Series 60 went belly-up many years ago, long before there was any widespread interest in developing mobile applications. Also, all these points don't stand today, since Symbian is now a full platform with a single code repository and no "UIs" above it. See symbian.org.
I disagree when people say that Symbian is outdated or "catching up". Actually, it's the other OS who have been slowly catching up with Symbian.
- Symbian has had video calling support since 3G day 0 - iOS is getting it in 2010 and Android IIRC still hasn't it (you have to install 3rd party applications to do something similar).
- Symbian has had fully programmable bluetooth (and built-in file transfer support) since day 0 - iOS still hasn't it, and Android only got it in 2.1 version.
- Symbian has had full multitasking since day 0 - iOS is getting it in 2010, and half-baked.
- Symbian has had the ability to install applications in memory cards since day 0 - iOS doesn't support external media at all, and Android only got it in 2.2 version.
- Symbian has had a webkit-based web browser since before the iPhone came out.
- Symbian has had FM radio support since day 0 - iOS doesn't support it, and Android only got it in 2.2 version.
- Symbian has supported MMS, photo galleries, media- and playlist- editing, since forever - al things iOS and Android are only starting to get now (and whenever iOS catches up with something other platform have been able to for years, reviewers see a "revolution" instead).
- Symbian can be programmed in Java, Python, Flash, C++, Qt, WebRT - all officially supported runtimes with platform-specific APIs to access the phone hardware features. I think it's still the mobile platform which gives the developer the most choices.
- Except for the application signing hassle, Symbian is fully open: to sync, you can use SyncML; to send files, you use OBEX; and you can use them over almost any transport, be it TCP, Bluetooth, USB or IrDA. To load media on it, you can use MTP or just throw MP3s on the phone by using it as a USB MSD. Your phone hasn't got a GPS? You can use any bluetooth-based GPS receiver sending plain NMEA over a plain bluetooth serial link (this means you can recycle your receiver to use it with another open platform, for instance your netbook). Want to print some photos? You can just connect the phone to a PictBridge printer. You want to send a contact to somebody near you? You can send your phonebook entries as a vCard (including the contact photo) over Bluetooth (or SMS IIRC). See, there's almost never proprietary stuff involved.
The only field where Symbian has been lagging behind, is its UI. Which is very old-fashioned, but functional. Something they're definitely addressing in new releases. Also, to be honest, I think they need to drop the "phone memory" / "mass storage" distinction which I find very confusing, and overall improve the management of applications' life cycle.
It's how the media system works, it works both ways.
Anyway, it looks like in the end this will result in an improvement of the working conditions at Foxconn thanks to Apple, which will in turn get a benefit in terms of image.
ARM processors don't come pre-packaged. You license the core design, then you have to do everything else is needed to turn that into a physical chip. That's what *every SOC manufacturer* who uses an ARM chip does. Thus every ARM-based chip out in the wild is "different from any other chip". And we should get a slashdot story for each one of them.
Because Apple isn't responsible for the salaries of Foxconn employees?
Apple IS responsible, because they know the workers' conditions, and still accept to make business with their direct employers. Those workers work FOR Apple, it doesn't matter how long the control chain between Apple and them is.
Lots of phones had browsers on them before the iPhone. They were completely useless.
This is false.
You understand how it works right? You call someone on the _phone_, and if they can support it, you can enter a video chat from _within the call_. I'm sorry, but that is a huge improvement on current tech.
Actually, that's how every 3G phone in the world works. And they have worked this way for 7 years or so.
Coincidentally this is exactly what MS is doing with Windows Phone 7 -- three hardware platforms, that's it. You still have to design your app three times, but at least you know that if you design for one hardware platform, ANY device within that platform by ANY manufacturer on ANY carrier will have the same exact limitations and abilities.
It's a bit too convenient, because MS is just starting anew. What do you think will happen when those three platforms start getting obsolete?
2 - We hate android beacuse its not predictable ( but open )
I bought an Android phone because it was supposed to be "open". Then I found that it's locked down to the bootloader, that I can compile the code downloaded from source.android.com but then I have no way of running it on the phone, and that even if I found some warranty-voiding hack to do it, I would lose all google apps, the marketplace, and an assorted array of hardware functionality such as camera and FM radio. Sigh.
At least Apple will upgrade their phones until it's technically not feasible for them to do so. I think they're the only phone manufacturer with such a policy.
Blackberry and Nokia do release some upgrades for their phones - at least they own hardware of the devices they sell, so it's easier for them to do so, although carriers usually get in their way.
Google is in the worst position since it only controls the core software platform (except for the case of the Nexus One). A phone won't receive an upgrade unless both the phone manufacturer and the carrier are interested in it. Which is a pretty rare combination.
Yes, but even applications running under virtual machines use APIs, and Google spits out a new API every 3 months. Phones in general will NOT be upgraded to support the new APIs (it's an exception when they are), and developers have to either resort to multiple code paths for backwards compatibility, or drop support for older phones (where "older", here, means older than a couple of months). That's the issue of fragmentation.
-- An angry Android user stuck with Android 1.6 on a six months old phone, which received 0 updates from its manufacturer, and is frustrated from seeing applications disappear from the Market because they require 2.1
Odd, I'm looking at http://www.kernel.org/pub/linux/kernel/v2.6/ and the latest kernel I see is 2.6.33, and that comes in at a whopping 81 megabytes for the compressed tarball.
Hey, look better and you'll find that the.bz2 compressed tarball is 63 MB.
Anyway, if we look at the uncompressed size of some other projects, we see that, for instance, vim is 60M, glibc takes 188 MB, kde is 1,5 GB and tex (binary) is 2 GB! In comparison, Linux seems pretty average to me.
Apple has managed to write their driver stack in C++ with AFAIK no binary compatibility breakage since they switched from GCC 2.95 to GCC 3 way back in 2003....
Sigh, in the GNU world, we've had much more frequent C++ ABI breakages, so when I hear "C++" and "binary compatibility" in the same phrase, I start to be afraid;) .
Why, if they can't release the source code, they will do what they've been doing for years: release a proprietary driver consisting of a binary-only blob, glued to the kernel with an open-source shim.
There's no need for an ABI for manufacturers to support Linux. It's just one of the excuses adduced by the manufacturers who have no interest in supporting it.
An ABI is not in the interest of Linux users. It's only in the interest of lazy manufacturers who want to push pieces of hardware which users will have to trash after the next operating system release. I've got plenty of hardware I can no longer use under Windows because its manufacturers only produced ONE release of the driver before shelving the product. All of it works with Linux.
"Too large" for what? The latest linux kernel weighs 60 MB; in comparison, the latest ATI display drivers for windows take 52 MB (and they only support the latest graphics cards). Moreover, source updates only need to transfer the changes, which will usually be very small for legacy drivers, whose code is stable. The whole 2.6.32 -> 2.6.33 kernel patch is less than 10 MB big. I cant'see this as a problem in the ADSL / HSPA era, and in fact I thought that the current trend for distributed development was to switch from the traditional sets of tarballs + patches to a single, large git (or equivalent) repository.
Redesign the kernel interfaces in an object-oriented language. Such designs make it more likely that drivers can extend the interfaces without requiring major changes to the core code. The Linux kernel sort of halfway adopts this approach insofar as code reuse is concerned, but does so in ways that aren't particularly clean and neat.
For example, if I were writing an ATA driver and needed to do almost everything the same way but change the behavior of one function in some other library... say down at the block device layer, I'd either have to make a change to the block device layer with some special case detection code or I'd have to copy entire swaths of code at the ATA device layer and change the calls to that function to point to my own function. Eventually that might become a function pointer variable, but until then, it's a mess (and, arguably, huge piles of function pointers are still something of a mess).
With an OO language, I'd just override one method in my class and I'd be done. No muss, no fuss.
But doesn't "just overriding one method in a class" mean changing a function pointer? It's not that if you use a derived class for your driver, all the other drivers will magically use the derived class instead of the one they were designed and compiled for. Would converting the whole linux kernel to C++ just to get the syntactic sugar be worth the effort? Also consider that C++ is less supported on embedded systems, and has a much more complex (and changing) ABI than C.
Yes, the effects of that weapon on people are horrific and not easy to watch, but don't let your horror override your reason.
Yeah, the excitement of the soldiers at killing people, the fun they had when a tank crushed a (hopefully) dead body, their instant self-acquittal when they realized they had shot two little girls... my reason must be really overridden to find that to be a crime, that shouldn't be taken in the name of justice.
Those gunships were flying top cover for a ground patrol. (This is all direct from the voice traffic on the video) The ground patrol said they saw people with weapons up ahead, and they asked the air element to have a look.
The air element saw a group of people - not a "crowd" by any means; that's just sensationalism - and saw weapons in the group. According to their ROE, they are allowed to engage armed persons who appear to be a threat (in this case, to the ground patrol) and they did so.
I don't know which is worse - disemboweling innocent people who had the bad luck of "appearing to be a threat", trying to minimize as "sensationalism" a count of over 12 innocent people killed, or clinging to ROE to justify an unuseful massacre.
The gunner is very keen to have the wounded target pick up a weapon, because that would allow him to open fire again, but he holds fire as required to.
Another nicety to note is that the gunner is *eager* to find a justification to kill a wounded, crawling, unarmed civilian. And he is later pretty quick to find it, in the fact that other civilians are carrying him away, most probably to cure him. Which, by the way, somehow gave him the justification to kill all other unarmed civilians around there, while he was at it.
In other frames, it is more clearly a camera - but I also have the benefit of *knowing* that it *is* a camera. I'm not in a gunship orbiting what I think is an ambush in the making with my buddies' lives in the balance.
From the POV of the ground forces and the gunship, they were seeing an ambush. Based on the activity in the area at the time, which almost certainly had included other, actual ambushes, they were probably pre-disposed to interpret what they saw as an ambush.
So what we have is a tragic case of mistaken identity.
That's terrible, but it happens.
Does this mean that armed forces are allowed to kill without hesitation anybody carrying a camera? If it is so, then say it and let people judge the appropriateness of such a rule. Otherwise, find the responsibles of this "tragic case of mistaken identity" and make him pay for their mistakes like we're used to do in democracies. Which I doubt will ever happen.
It is one of the consequences of guerrilla warfare - when friend and foe look alike, mistakes will be made.
In fact, after seeing this video, I find myself pretty confused over who's the foe and who's the friend. Surely the girls on the rescue van weren't foes. Which might be the reason why the government tried to hide this video, censor those who found it, and above all, why they lied about the facts. If everything was OK, then they would have nothing to hide.
I note too that when the area is deemed secure and the ground patrol shows up, they apply first aid to the wounded and evacuate them.
...after crushing their bodies with a tank. And having a laugh over it.
This is what war is like. It's not at all pretty, or clean. And when your tools are high-powered weapons, the consequences of mistakes are high and that sucks for all involved.
Then it must be stopped, not justified.
that won't remove the necessity of applying lethal force to the enemies of civilization
Can't you see there is no *civilization* in that video?
nor will it bring back to life those killed in error when mistakes are made.
It's needed to reassert the fact that we, the occidental forces, are the ones that fight in the name of justice and under the rule of law.
Slashdot Mirror
1) You want to support phones that were manufactured in 2004? How many of them will be still functional in 2010?
2) The first App Store, Apple's, wasn't open until 2008 so how could its existence be a deciding factor in 2005?
3) Do all 2.1 Android apps work unmodified on 1.6 handsets? Will iOS 4 support 1st gen iPhones?
I think your analogy is not accurate because:
- Nokia said that all future *n-series* devices would not run Symbian^3. Thus c-series, e-series and x-series are getting Symbian^3 in the future. N-series is a small part of Nokia's sales.
- Nokia *is* developing a next version of Symbian, which is not Meego (that replaces Maemo), but Symbian^4. A few days ago they confirmed that future n-series devices will get Symbian^4 too (and it's not vapourware, since anybody can follow Symbian^4 development on symbian.org).
Sony and Samsung sell high-end Symbian phones. In fact, the most powerful Symbian phones currently on the market are not from Nokia.
Yes, but the Nuron is a crippled version of the 5230, which in its turn is already a cheap phone. If this is the best Nokia offers in the USA, then I begin to understand why Nokia has such a thin market share there.
You could have bought a 5800, it would have costed you less than half the money as the N97, and still have more features than any remotely comparable phone in that price range. Nokia flagships are very overpriced, they've always been, because apparently there are people who buy them anyways. Perhaps the N97 debacle will change things, and in fact it looks like the N8 will be quite affordable.
- Treating the app developer as some annoyance to be fobbed off whenever possible. No idea what's it's like now, but back in the day, to develop an app for Symbian you have to splash out on a compiler which retailed at over $2k. And if god forbid you wanted to actually debug code running on your device (rather than the not particularly good emulator), well, then you need a HW debugger box which ran to another $2k
Yes, but the compiler has now been free for years, and in particular has been free since *before* the iPhone and Android existed. So if you really were interested in a fair comparison, you would compare Symbian with the alternatives of the time. Today Symbian is fully free, as in speech - you can hg clone the whole OS.
- Completely and comprehensively fragmenting the eco-system whenever the slightest opportunity to do so arose. Hence Symbian never really existed as a platform per se - it was all an obscure and vast ecosytem of devices each with its own configuration - hence the prolliferation of Series 40, 60, 70, UIQ etc etc.
Series 40 was never Symbian-based, so you're just trolling here. Series 70 never existed. Moreover, everything different than Series 60 went belly-up many years ago, long before there was any widespread interest in developing mobile applications. Also, all these points don't stand today, since Symbian is now a full platform with a single code repository and no "UIs" above it. See symbian.org.
I disagree when people say that Symbian is outdated or "catching up". Actually, it's the other OS who have been slowly catching up with Symbian.
- Symbian has had video calling support since 3G day 0 - iOS is getting it in 2010 and Android IIRC still hasn't it (you have to install 3rd party applications to do something similar).
- Symbian has had fully programmable bluetooth (and built-in file transfer support) since day 0 - iOS still hasn't it, and Android only got it in 2.1 version.
- Symbian has had full multitasking since day 0 - iOS is getting it in 2010, and half-baked.
- Symbian has had the ability to install applications in memory cards since day 0 - iOS doesn't support external media at all, and Android only got it in 2.2 version.
- Symbian has had a webkit-based web browser since before the iPhone came out.
- Symbian has had FM radio support since day 0 - iOS doesn't support it, and Android only got it in 2.2 version.
- Symbian has supported MMS, photo galleries, media- and playlist- editing, since forever - al things iOS and Android are only starting to get now (and whenever iOS catches up with something other platform have been able to for years, reviewers see a "revolution" instead).
- Symbian can be programmed in Java, Python, Flash, C++, Qt, WebRT - all officially supported runtimes with platform-specific APIs to access the phone hardware features. I think it's still the mobile platform which gives the developer the most choices.
- Except for the application signing hassle, Symbian is fully open: to sync, you can use SyncML; to send files, you use OBEX; and you can use them over almost any transport, be it TCP, Bluetooth, USB or IrDA. To load media on it, you can use MTP or just throw MP3s on the phone by using it as a USB MSD. Your phone hasn't got a GPS? You can use any bluetooth-based GPS receiver sending plain NMEA over a plain bluetooth serial link (this means you can recycle your receiver to use it with another open platform, for instance your netbook). Want to print some photos? You can just connect the phone to a PictBridge printer. You want to send a contact to somebody near you? You can send your phonebook entries as a vCard (including the contact photo) over Bluetooth (or SMS IIRC). See, there's almost never proprietary stuff involved.
The only field where Symbian has been lagging behind, is its UI. Which is very old-fashioned, but functional. Something they're definitely addressing in new releases. Also, to be honest, I think they need to drop the "phone memory" / "mass storage" distinction which I find very confusing, and overall improve the management of applications' life cycle.
Except for playing (offline) games, you can't do any of the things you said with no signal.
Anyway, it looks like in the end this will result in an improvement of the working conditions at Foxconn thanks to Apple, which will in turn get a benefit in terms of image.
I'm sure many people from Louisiana are finding your comment funny.
ARM processors don't come pre-packaged. You license the core design, then you have to do everything else is needed to turn that into a physical chip. That's what *every SOC manufacturer* who uses an ARM chip does. Thus every ARM-based chip out in the wild is "different from any other chip". And we should get a slashdot story for each one of them.
Because Apple isn't responsible for the salaries of Foxconn employees?
Apple IS responsible, because they know the workers' conditions, and still accept to make business with their direct employers. Those workers work FOR Apple, it doesn't matter how long the control chain between Apple and them is.
Lots of phones had browsers on them before the iPhone. They were completely useless.
This is false.
You understand how it works right? You call someone on the _phone_, and if they can support it, you can enter a video chat from _within the call_. I'm sorry, but that is a huge improvement on current tech.
Actually, that's how every 3G phone in the world works. And they have worked this way for 7 years or so.
Historically, majorities have often been wrong.
It would be nice if there was a standard for video calls on phones.
Isn't that standard since 2003 or so? Even the cheapest 3G phones support it.
Coincidentally this is exactly what MS is doing with Windows Phone 7 -- three hardware platforms, that's it. You still have to design your app three times, but at least you know that if you design for one hardware platform, ANY device within that platform by ANY manufacturer on ANY carrier will have the same exact limitations and abilities.
It's a bit too convenient, because MS is just starting anew. What do you think will happen when those three platforms start getting obsolete?
2 - We hate android beacuse its not predictable ( but open )
I bought an Android phone because it was supposed to be "open". Then I found that it's locked down to the bootloader, that I can compile the code downloaded from source.android.com but then I have no way of running it on the phone, and that even if I found some warranty-voiding hack to do it, I would lose all google apps, the marketplace, and an assorted array of hardware functionality such as camera and FM radio. Sigh.
Blackberry and Nokia do release some upgrades for their phones - at least they own hardware of the devices they sell, so it's easier for them to do so, although carriers usually get in their way.
Google is in the worst position since it only controls the core software platform (except for the case of the Nexus One). A phone won't receive an upgrade unless both the phone manufacturer and the carrier are interested in it. Which is a pretty rare combination.
-- An angry Android user stuck with Android 1.6 on a six months old phone, which received 0 updates from its manufacturer, and is frustrated from seeing applications disappear from the Market because they require 2.1
In fact, the controversial bits of the EULA haven't changed since the original 1.0 revision of 2006, and the whole article is basically wrong.
There's a huge market for $600 phones... for kids?
Hey, look better and you'll find that the .bz2 compressed tarball is 63 MB.
Anyway, if we look at the uncompressed size of some other projects, we see that, for instance, vim is 60M, glibc takes 188 MB, kde is 1,5 GB and tex (binary) is 2 GB! In comparison, Linux seems pretty average to me.
Sigh, in the GNU world, we've had much more frequent C++ ABI breakages, so when I hear "C++" and "binary compatibility" in the same phrase, I start to be afraid ;) .
An ABI is not in the interest of Linux users. It's only in the interest of lazy manufacturers who want to push pieces of hardware which users will have to trash after the next operating system release. I've got plenty of hardware I can no longer use under Windows because its manufacturers only produced ONE release of the driver before shelving the product. All of it works with Linux.
The tree is already too large.
"Too large" for what? The latest linux kernel weighs 60 MB; in comparison, the latest ATI display drivers for windows take 52 MB (and they only support the latest graphics cards). Moreover, source updates only need to transfer the changes, which will usually be very small for legacy drivers, whose code is stable. The whole 2.6.32 -> 2.6.33 kernel patch is less than 10 MB big. I cant'see this as a problem in the ADSL / HSPA era, and in fact I thought that the current trend for distributed development was to switch from the traditional sets of tarballs + patches to a single, large git (or equivalent) repository.
Redesign the kernel interfaces in an object-oriented language. Such designs make it more likely that drivers can extend the interfaces without requiring major changes to the core code. The Linux kernel sort of halfway adopts this approach insofar as code reuse is concerned, but does so in ways that aren't particularly clean and neat.
For example, if I were writing an ATA driver and needed to do almost everything the same way but change the behavior of one function in some other library... say down at the block device layer, I'd either have to make a change to the block device layer with some special case detection code or I'd have to copy entire swaths of code at the ATA device layer and change the calls to that function to point to my own function. Eventually that might become a function pointer variable, but until then, it's a mess (and, arguably, huge piles of function pointers are still something of a mess).
With an OO language, I'd just override one method in my class and I'd be done. No muss, no fuss.
But doesn't "just overriding one method in a class" mean changing a function pointer? It's not that if you use a derived class for your driver, all the other drivers will magically use the derived class instead of the one they were designed and compiled for. Would converting the whole linux kernel to C++ just to get the syntactic sugar be worth the effort? Also consider that C++ is less supported on embedded systems, and has a much more complex (and changing) ABI than C.
Yes, the effects of that weapon on people are horrific and not easy to watch, but don't let your horror override your reason.
Yeah, the excitement of the soldiers at killing people, the fun they had when a tank crushed a (hopefully) dead body, their instant self-acquittal when they realized they had shot two little girls... my reason must be really overridden to find that to be a crime, that shouldn't be taken in the name of justice.
Those gunships were flying top cover for a ground patrol. (This is all direct from the voice traffic on the video) The ground patrol said they saw people with weapons up ahead, and they asked the air element to have a look.
The air element saw a group of people - not a "crowd" by any means; that's just sensationalism - and saw weapons in the group. According to their ROE, they are allowed to engage armed persons who appear to be a threat (in this case, to the ground patrol) and they did so.
I don't know which is worse - disemboweling innocent people who had the bad luck of "appearing to be a threat", trying to minimize as "sensationalism" a count of over 12 innocent people killed, or clinging to ROE to justify an unuseful massacre.
The gunner is very keen to have the wounded target pick up a weapon, because that would allow him to open fire again, but he holds fire as required to.
Another nicety to note is that the gunner is *eager* to find a justification to kill a wounded, crawling, unarmed civilian. And he is later pretty quick to find it, in the fact that other civilians are carrying him away, most probably to cure him. Which, by the way, somehow gave him the justification to kill all other unarmed civilians around there, while he was at it.
In other frames, it is more clearly a camera - but I also have the benefit of *knowing* that it *is* a camera. I'm not in a gunship orbiting what I think is an ambush in the making with my buddies' lives in the balance.
From the POV of the ground forces and the gunship, they were seeing an ambush. Based on the activity in the area at the time, which almost certainly had included other, actual ambushes, they were probably pre-disposed to interpret what they saw as an ambush.
So what we have is a tragic case of mistaken identity.
That's terrible, but it happens.
Does this mean that armed forces are allowed to kill without hesitation anybody carrying a camera? If it is so, then say it and let people judge the appropriateness of such a rule. Otherwise, find the responsibles of this "tragic case of mistaken identity" and make him pay for their mistakes like we're used to do in democracies. Which I doubt will ever happen.
It is one of the consequences of guerrilla warfare - when friend and foe look alike, mistakes will be made.
In fact, after seeing this video, I find myself pretty confused over who's the foe and who's the friend. Surely the girls on the rescue van weren't foes. Which might be the reason why the government tried to hide this video, censor those who found it, and above all, why they lied about the facts. If everything was OK, then they would have nothing to hide.
I note too that when the area is deemed secure and the ground patrol shows up, they apply first aid to the wounded and evacuate them.
...after crushing their bodies with a tank. And having a laugh over it.
This is what war is like. It's not at all pretty, or clean. And when your tools are high-powered weapons, the consequences of mistakes are high and that sucks for all involved.
Then it must be stopped, not justified.
that won't remove the necessity of applying lethal force to the enemies of civilization
Can't you see there is no *civilization* in that video?
nor will it bring back to life those killed in error when mistakes are made.
It's needed to reassert the fact that we, the occidental forces, are the ones that fight in the name of justice and under the rule of law.
import static java.lang.System.out;
class Test {
public static void main(String[] args) {
out.println("Hey");
}
}