That's the wrong question. The right question is this:
What fundamental problem cannot be solved by trivially tweaking or skinning the existing OSes?
If you have an answer for that question, then clearly there's a need for a third OS. If the new OS is just going to be a knock-off of iOS and Android with nothing fundamentally different, then you might as well just use Android and avoid trifurcating the developer community.
A one person coding shop should not be taking on projects of that scale.
What scale? Every network-using app from the most basic cloud-synchronized pedometer to the most complex stock trading app requires security, and the vast majority of developers need to do things like be able to make debug builds of their app be able to communicate with random internal test servers (possibly even servers specific to a given unit test) without every developer having to have an individual key and cert. That implies nothing about the scale of the app; it is a problem from one-person shops up through very large development shops. And the way you do such things involves mucking with security code.
The problem comes when that code accidentally gets deployed in production. Suddenly, code that was never intended to be secure had better be. And this is why it is so important that Stack Overflow answers always tell people how to do it the right way, not the fast way.
If I'm asked to perform surgery on a patient as an outsourced contractor, it is my ethical duty to refuse no matter how many episodes of E.R. I have watched.
To map your analogy onto the real-world security failures that we've frequently seen, the problem comes when you're asked to merely play one on TV while blindfolded, and then you later find out that you were cutting into an actual patient, and the patient died.
I mean that the GP post relative to my post said that he/she couldn't reply to comments on his/her own answers. Whether that's true or not, or whether it has ever been true or not, I couldn't say.
Christians have been on the watch out for a one world government that controls all trade.
Most Christians generally recognize that Revelation was about Emperor Nero, some two thousand years ago. How do we know this? Hebrew letters also have a numerical value, and the Hebrew letters for Nero's name sum to 666. The rest of the things in Revelation are also historical, mapping onto actual events not long after the time of Christ. There's no biblical support for the view that anything in Revelation is about the future (anymore). It's all ancient history (now).
Biometrics, as a class, can not successfully be used to solve authentication problems because once lost, they can not be changed. They are excellent for identification problems: UUID's, primary keys, usernames. But they make terrible passwords and must not be used for authentication.
Exactly. It is provably impossible to guarantee a trusted endpoint when under someone else's control, and that's where any sort of identifier breaks down for authentication purposes, no matter how seemingly unique.
Consider the example of the sorts of things Equifax is intended to protect—obtaining credit. Half the time, people apply for credit cards online using their own computers, and people use their computers for online banking, etc. To facilitate this, the credit agencies convince all of the computer and cell phone manufacturers to include built-in iris scanners.
Jump forward ten years. Every computer has an iris scanner built in. Everyone uses their iris scans for everything, from buying things online to getting money from an ATM. So suppose some malicious person wants to get a credit card in my name. Let's look at how this scheme can be compromised, one step at a time.
Compromise the credential: The attacker first needs to get my iris scan data. To do this, they install a skimmer that attaches to the image sensor in my bank/credit union's ATM. It then sends that scan data to the attacker.
Use the credential: The attacker modifies an iris scanner on a personal computer to send arbitrary iris scan data instead of what was actually scanned.
And now, somebody has a credit card in my name. And according to the credit card company, it was me, because after all, who else could have applied for a credit card using my iris scan?
Iris scans might be acceptable for identification purposes under very controlled circumstances (e.g. at the teller window inside a bank). But for authentication purposes, it has exactly the same problem as a social security number. As you said, it is really useful only as an identifier, not as a form of authentication.
No surprise, then, that the same bozos who brought us a fundamentally broken system of trust based on secret numbers would try to do exactly the same thing, just with a different secret number generated from a fingerprint or iris scan. When all you have in your mental toolbox is a hammer, everything looks like a nail.
To solve this problem, we need to start by finding people with a bigger mental toolbox. If Equifax and friends were capable of solving this problem, they would have done it years ago.
And let's face it. If the question is about security, you do NOT want to get your answer from stack overflow, slashdot, reddit, facebook or any other source of crowd sourced prognostications. If you have to ask the question, you should not be touching the security code and should leave it to the experts on staff; if you don't have such experts, then try to get some; if you can't get one, then change jobs.
There are way too many one-person coding shops for that to be a realistic recommendation. Just saying.:-)
This is why I make sure to actually read the existing answer(s) before flagging something as a duplicate. If there's no currently valid answer, I just write an answer. If somebody wants to take the time later to flag it as a duplicate and merge it with the other question, fine, but in the grand scheme of things, it is better *not* to do so. After all, the old, no-longer-valid answer will likely continue to be the highest-ranked answer for that old question, barring a miracle, but a new answer could become the highest-ranked answer for a new question. And over time, the page for that old question and answer will slowly diminish in page rank due to lack of inbound links, and the page for the new question will increase in rank due to recency. So the result will be that the most easily found answer will be correct as long as you keep them separate. If you merge them, the most easily found answer will remain wrong forever.
That said, those that start with a very high level language usuallly have the same problem just with a different view at it. They still only have a few key rules of thumb, this time applied to the few frameworks or libraries that they understand; their code is so chock full of abstraction layers that no one else understands any of it or is capable of make small modifications safely. They think they understand the big picture only because they've labelled it as "BigPictureInstanceFactory".
That's easily solved. Just introduce dependency injection. Then, even your expert programmers will be unable to understand the big picture, and everyone will be equally confused.
Except that most programmers are terrible and so is their code. Very rarely have I read code written by somebody else that I truly admired.
Well, yeah, but you didn't get to that point by not reading their code. You got there by looking at bad code, understanding it, and concluding that it was bad. If you had never seen bad code before, how would you recognize it when you saw it?
I used to say this a lot; however, I was given an analogy that made me change my mind. When we teach people to drive, we don't make them learn on snow and ice. So why should we make them do that with programming?
You must live in an area that doesn't get much snow or ice if that made you change your mind. Where I come from (Tennessee), we got a bad snowstorm one or two times a year, and if you didn't want to be trapped in a house with no power, no phone, and no heat, you had better be prepared to drive in snow and ice. Most people I know from back home had their first driving experience—often even before getting their learners' permits and learning to drive on actual streets—by going to some large, wide-open parking lot for some random not-open business and learning how cars behave in the worst conditions.
This has multiple purposes. For one, it makes you appreciate how treacherous driving can be, so you're more careful from then on. For another, you understand exactly how your car behaves in terms of sliding under various amounts of throttle, various amounts of turning, etc. Then, every time you drive a new car in rain, you use those same techniques to quickly learn how much centrifugal force causes the car to start spinning, and you make d**n sure you never come close to exceeding that. People not learning how to drive in snow and ice are the reason we have so many people carelessly spinning their cars around backwards and having wrecks every time there's a light rain in northern California.
Learning C is much the same.
IMO, Java's biggest problem is that object-oriented programming is a terrible way to start learning programming, because it doesn't map very well onto the way humans think about the world. By and large, people think procedurally, not OOPy, not functionally. Yet instructors are forced to introduce concepts like classes and methods really early in Java classes—long before the students actually understand these concepts—because the students have to use classes and methods to do even the most basic things like printing "Hello, world." And unfortunately, C++ has the same problem unless you teach it like C.
I've concluded that schools really should start with a purely procedural language for teaching the basics of programming, not an OO language. Then, move on to data structures—still in a procedural language—for the second class. Finally, teach OOP as the third class. By that point, you can tell them that a class is a glorified struct with syntactic sugar and that methods are glorified function pointers with syntactic sugar. You can also easily explain how to think in an object-oriented fashion and organize code in an object-oriented fashion, because the students have enough grounding in the basics of programming to make that logical leap. And if you do it right, you can also be subtly encouraging OO-like design even within the procedural code, so that objects become natural extensions of things like "static", rather than being a completely foreign concept.
I should also have pointed out that not all phones will necessarily support *every* LTE band of the other carrier, but fortunately, the towers are already smart enough to handle those sorts of allocation difficulties, ensuring that phones don't get assigned to bands that they don't support.
My cell phone can detect shifts in the center of mass during turns and vibrations from the car or terrain. Accelerometers aren't exactly crazy high tech.
That's not entirely true. My Sprint iPhone can roam onto T-Mobile's network just fine (and occasionally does in the very rare spots where T-Mobile has coverage and Sprint doesn't). And even T-Mobile cell phones can use Sprint's LTE network, assuming they support the right bands. They just can't use their 3G network (for lack of a CDMA radio). In urban areas where LTE is readily available, the networks could complement each other nicely.
I still don't like the idea of consolidation, though. We have way too few nationwide cellular networks as it is. We need about ten more, not fewer.
With frequency bands from 2.3 to 2.4 GHz. and 2.496 to 2.69 GHz, respectively, LTE bands 40 and 41 are essentially on either side of the ISM band, which is from 2.4 to 2.5 GHz.
The poor coverage has nothing to do with microwave ovens and everything to do with higher frequencies being more prone to multipath interference. That's the highest-frequency band that Sprint uses for LTE.
Removable batteries doesn't solve the problem. It allows you to replace the battery more easily, IF it hasn't done a great deal of damage. And removable batteries don't prevent the battery from burning a hole in your pants.
Actually, part of the nature of a removable battery design is that the back has to be readily removable, which means unless it is designed badly, an expanding battery will not cause permanent damage. Rather, it would push the battery cover off, allowing the battery to expand safely. Upon seeing that, you'd just have to pull the battery out, replace it, and snap the cover back on. No big deal.
Also, one big cause of fires is compression of the battery, which can happen as a side effect of the battery expanding in the wrong way within an enclosed space. So because of that inherent safety valve (the battery cover), a removable battery design should be much less prone to catching fire as well.
This, of course, ignores the added risk of third-party removable batteries, but that's orthogonal.
Agreed. Also, I've frequently had problems on recent Apple hardware such that power cycling the Wi-Fi radio was the only way to get it working again (2013 Retina MBP, I'm looking at you). If this brain damage bleeds over to OS X, that's going to mean completely powering off my laptop once every few days.
I turn it off to stop it connecting to bad APs. I want it to turn back on if I'm at work or home or Starbucks where I don't want it using up my contract data balance because there's working wifi.
You know there's an button to forget a Wi-Fi network and an option to not automatically connect to unknown networks, right? And that those features have been around since... IIRC iPhone OS 1.0, give or take?
Like Apple, wired is still an option with Google using an included adapter.
Unlike Apple, they use the same USB-C port on their laptops, so you can buy an adapter and leave it permanently on the headphones. On Pixel, it's really not a big deal; it's just a temporary dongle until the last of your hardware moves to USB-C, and then it is a ubiquitous connector. On iPhone, it's a significant usability problem, because you have to constantly connect and disconnect the adapter when you move the headphones from your Mac to your cell phone, and when it is connected to your Mac, you have to keep up with a loose adapter.
If Apple had ditched Lightning in favor of USB-C at the same time, there would have been a lot fewer complaints. Then again, at least Apple didn't remove the headphone jack on the MacBook Pro in favor of USB-C like they were reportedly considering doing. Can you imagine having to carry two different dongles just to use a proper pair of headphones with their hardware? That would be enough to make me sell off all my Apple stock and declare them beleaguered again.:-)
The thing is quality wise in a standard well lit scenario it is very difficult to tell a cellphone from a DSLR. It's only when you want to get fancy, depth of field, low light, non standard zoom ranges (the GP calling out the ability to zoom as a killer feature makes a mockery of those of us with 50mm f/1.2 lenses), or issues which demand extreme dynamic range, THEN the DSLR stands out.
The 50mm f/1.2 is a nice portrait lens, but the differences aren't the sort of thing that the average person is likely to appreciate, which makes it a bit of a specialty thing. Being able to zoom or change lenses to get additional reach, by contrast, isn't at all uncommon. The classic example I usually give when pointing out how much cell phones suck for photography is the parent wanting to take pictures of his/her kid's dance recital or piano recital or band concert or whatever:
The cell phone user gets a picture of the entire stage, and the kid is a small, blown-out smudge.
The DSLR owner sticks a 75-300L (or cheaper cousin thereof) on the camera and gets everything from a full-body shot to a close-up of the kid's head.
The cell phone user wants a closer shot, so he/she walks up onstage in the middle of the concert and is escorted out by security.
The DSLR owner enjoys the rest of the concert and shoots great close-up video of the cell phone user as he/she is dragged out of the recital hall kicking and screaming. "This is so going on Facebook," he/she says as he/she launches the app on his/her phone to grab the video clip and post it.
And they shouldn't be doing that. It causes most intelligent people to assume that the number of people who actually care about the issue is approximately zero. If you don't care enough to actually write something, you probably don't care much about it.
Worse, it does more harm than good. The FCC process is not a vote. It's an opportunity to raise new points about why you think the commissioners are complete idiots. If you aren't raising new valid points, then all you're doing is increasing the noise floor relative and making it harder to find the actual signal—the new points that need to be addressed. Every time someone copies and pastes somebody else's letter, they're actually harming their own position by making it more likely that the useful content will get lost in the noise.
These advocacy and lobby groups that do this need to just go away. If they can't successfully convince people to learn about the issues and write their own letters, then they aren't contributing usefully to the process, and their 501(c)3 status is a waste of taxpayer dollars.
I don't think you can automatically assume "bot" just from a lot of repeated comments. I'm not saying they're all not bots. I'm just saying it is common to see identical comments from non-bot entities.
True, but I think you can safely assume that those copy-and-paste jobs are utterly irrelevant, because:
A. They almost invariably reflect an uninformed opinion. People who actually understand an issue won't copy and paste somebody else's text, because they will have their own personal reasons for their opinions, and will want to express their reasons, not somebody else's.
B. They reflect an opinion that isn't strong enough to compel its holder to spend more than a few seconds copying and pasting something. People who actually hold a strong opinion will take the time to write something personal.
So whether the posters are bots or not, the posts are still noise. At best, they're uninformed people who have been swayed by an astroturfing campaign by their ISPs that encouraged them to copy and paste something without really understanding it, in which case their opinions are ill-informed and could turn on a dime if they became well-informed on the subject or if someone else screamed more loudly. At worst, they're programmatic bots paid for by ISPs, and they all represent the opinions of one or two actual people. Either way, they should be treated as the opinions of the one or two people who organized the campaign, because they're the only people who actually felt strongly enough to write down their opinions.
A modern cell phone takes better pictures than a top-of-the-line DSLR from ~10 years ago. Those DSLR photos were touted as being great quality.
Not even close. A top-of-the-line DSLR from 10 years ago would be a Canon 1Ds Mk III. With a full-frame sensor at 21.1 megapixels, it wipes the floor with most smartphone cameras even if you don't factor in things like oh, I don't know, zoom lenses....
A modern cell phone takes great quality photos that are good enough for well over 95% of the population in over 95% of circumstances.
That would be the 95% of the population who have never used an actual camera, of course....
Slashdot Mirror
That's the wrong question. The right question is this:
What fundamental problem cannot be solved by trivially tweaking or skinning the existing OSes?
If you have an answer for that question, then clearly there's a need for a third OS. If the new OS is just going to be a knock-off of iOS and Android with nothing fundamentally different, then you might as well just use Android and avoid trifurcating the developer community.
What scale? Every network-using app from the most basic cloud-synchronized pedometer to the most complex stock trading app requires security, and the vast majority of developers need to do things like be able to make debug builds of their app be able to communicate with random internal test servers (possibly even servers specific to a given unit test) without every developer having to have an individual key and cert. That implies nothing about the scale of the app; it is a problem from one-person shops up through very large development shops. And the way you do such things involves mucking with security code.
The problem comes when that code accidentally gets deployed in production. Suddenly, code that was never intended to be secure had better be. And this is why it is so important that Stack Overflow answers always tell people how to do it the right way, not the fast way.
To map your analogy onto the real-world security failures that we've frequently seen, the problem comes when you're asked to merely play one on TV while blindfolded, and then you later find out that you were cutting into an actual patient, and the patient died.
I mean that the GP post relative to my post said that he/she couldn't reply to comments on his/her own answers. Whether that's true or not, or whether it has ever been true or not, I couldn't say.
Most Christians generally recognize that Revelation was about Emperor Nero, some two thousand years ago. How do we know this? Hebrew letters also have a numerical value, and the Hebrew letters for Nero's name sum to 666. The rest of the things in Revelation are also historical, mapping onto actual events not long after the time of Christ. There's no biblical support for the view that anything in Revelation is about the future (anymore). It's all ancient history (now).
Exactly. It is provably impossible to guarantee a trusted endpoint when under someone else's control, and that's where any sort of identifier breaks down for authentication purposes, no matter how seemingly unique.
Consider the example of the sorts of things Equifax is intended to protect—obtaining credit. Half the time, people apply for credit cards online using their own computers, and people use their computers for online banking, etc. To facilitate this, the credit agencies convince all of the computer and cell phone manufacturers to include built-in iris scanners.
Jump forward ten years. Every computer has an iris scanner built in. Everyone uses their iris scans for everything, from buying things online to getting money from an ATM. So suppose some malicious person wants to get a credit card in my name. Let's look at how this scheme can be compromised, one step at a time.
And now, somebody has a credit card in my name. And according to the credit card company, it was me, because after all, who else could have applied for a credit card using my iris scan?
Iris scans might be acceptable for identification purposes under very controlled circumstances (e.g. at the teller window inside a bank). But for authentication purposes, it has exactly the same problem as a social security number. As you said, it is really useful only as an identifier, not as a form of authentication.
No surprise, then, that the same bozos who brought us a fundamentally broken system of trust based on secret numbers would try to do exactly the same thing, just with a different secret number generated from a fingerprint or iris scan. When all you have in your mental toolbox is a hammer, everything looks like a nail.
To solve this problem, we need to start by finding people with a bigger mental toolbox. If Equifax and friends were capable of solving this problem, they would have done it years ago.
Arguably, being unable to comment on your own answers is a bug, regardless of reputation....
There are way too many one-person coding shops for that to be a realistic recommendation. Just saying. :-)
This is why I make sure to actually read the existing answer(s) before flagging something as a duplicate. If there's no currently valid answer, I just write an answer. If somebody wants to take the time later to flag it as a duplicate and merge it with the other question, fine, but in the grand scheme of things, it is better *not* to do so. After all, the old, no-longer-valid answer will likely continue to be the highest-ranked answer for that old question, barring a miracle, but a new answer could become the highest-ranked answer for a new question. And over time, the page for that old question and answer will slowly diminish in page rank due to lack of inbound links, and the page for the new question will increase in rank due to recency. So the result will be that the most easily found answer will be correct as long as you keep them separate. If you merge them, the most easily found answer will remain wrong forever.
*blink*. *blink*.
It's a miracle! Darinbob—in a coma since the Reagan administration—just woke up and posted on Slashdot!
That's easily solved. Just introduce dependency injection. Then, even your expert programmers will be unable to understand the big picture, and everyone will be equally confused.
Well, yeah, but you didn't get to that point by not reading their code. You got there by looking at bad code, understanding it, and concluding that it was bad. If you had never seen bad code before, how would you recognize it when you saw it?
You must live in an area that doesn't get much snow or ice if that made you change your mind. Where I come from (Tennessee), we got a bad snowstorm one or two times a year, and if you didn't want to be trapped in a house with no power, no phone, and no heat, you had better be prepared to drive in snow and ice. Most people I know from back home had their first driving experience—often even before getting their learners' permits and learning to drive on actual streets—by going to some large, wide-open parking lot for some random not-open business and learning how cars behave in the worst conditions.
This has multiple purposes. For one, it makes you appreciate how treacherous driving can be, so you're more careful from then on. For another, you understand exactly how your car behaves in terms of sliding under various amounts of throttle, various amounts of turning, etc. Then, every time you drive a new car in rain, you use those same techniques to quickly learn how much centrifugal force causes the car to start spinning, and you make d**n sure you never come close to exceeding that. People not learning how to drive in snow and ice are the reason we have so many people carelessly spinning their cars around backwards and having wrecks every time there's a light rain in northern California.
Learning C is much the same.
IMO, Java's biggest problem is that object-oriented programming is a terrible way to start learning programming, because it doesn't map very well onto the way humans think about the world. By and large, people think procedurally, not OOPy, not functionally. Yet instructors are forced to introduce concepts like classes and methods really early in Java classes—long before the students actually understand these concepts—because the students have to use classes and methods to do even the most basic things like printing "Hello, world." And unfortunately, C++ has the same problem unless you teach it like C.
I've concluded that schools really should start with a purely procedural language for teaching the basics of programming, not an OO language. Then, move on to data structures—still in a procedural language—for the second class. Finally, teach OOP as the third class. By that point, you can tell them that a class is a glorified struct with syntactic sugar and that methods are glorified function pointers with syntactic sugar. You can also easily explain how to think in an object-oriented fashion and organize code in an object-oriented fashion, because the students have enough grounding in the basics of programming to make that logical leap. And if you do it right, you can also be subtly encouraging OO-like design even within the procedural code, so that objects become natural extensions of things like "static", rather than being a completely foreign concept.
I should also have pointed out that not all phones will necessarily support *every* LTE band of the other carrier, but fortunately, the towers are already smart enough to handle those sorts of allocation difficulties, ensuring that phones don't get assigned to bands that they don't support.
My cell phone can detect shifts in the center of mass during turns and vibrations from the car or terrain. Accelerometers aren't exactly crazy high tech.
That's not entirely true. My Sprint iPhone can roam onto T-Mobile's network just fine (and occasionally does in the very rare spots where T-Mobile has coverage and Sprint doesn't). And even T-Mobile cell phones can use Sprint's LTE network, assuming they support the right bands. They just can't use their 3G network (for lack of a CDMA radio). In urban areas where LTE is readily available, the networks could complement each other nicely.
I still don't like the idea of consolidation, though. We have way too few nationwide cellular networks as it is. We need about ten more, not fewer.
With frequency bands from 2.3 to 2.4 GHz. and 2.496 to 2.69 GHz, respectively, LTE bands 40 and 41 are essentially on either side of the ISM band, which is from 2.4 to 2.5 GHz.
The poor coverage has nothing to do with microwave ovens and everything to do with higher frequencies being more prone to multipath interference. That's the highest-frequency band that Sprint uses for LTE.
Actually, part of the nature of a removable battery design is that the back has to be readily removable, which means unless it is designed badly, an expanding battery will not cause permanent damage. Rather, it would push the battery cover off, allowing the battery to expand safely. Upon seeing that, you'd just have to pull the battery out, replace it, and snap the cover back on. No big deal.
Also, one big cause of fires is compression of the battery, which can happen as a side effect of the battery expanding in the wrong way within an enclosed space. So because of that inherent safety valve (the battery cover), a removable battery design should be much less prone to catching fire as well.
This, of course, ignores the added risk of third-party removable batteries, but that's orthogonal.
Agreed. Also, I've frequently had problems on recent Apple hardware such that power cycling the Wi-Fi radio was the only way to get it working again (2013 Retina MBP, I'm looking at you). If this brain damage bleeds over to OS X, that's going to mean completely powering off my laptop once every few days.
You know there's an button to forget a Wi-Fi network and an option to not automatically connect to unknown networks, right? And that those features have been around since... IIRC iPhone OS 1.0, give or take?
Unlike Apple, they use the same USB-C port on their laptops, so you can buy an adapter and leave it permanently on the headphones. On Pixel, it's really not a big deal; it's just a temporary dongle until the last of your hardware moves to USB-C, and then it is a ubiquitous connector. On iPhone, it's a significant usability problem, because you have to constantly connect and disconnect the adapter when you move the headphones from your Mac to your cell phone, and when it is connected to your Mac, you have to keep up with a loose adapter.
If Apple had ditched Lightning in favor of USB-C at the same time, there would have been a lot fewer complaints. Then again, at least Apple didn't remove the headphone jack on the MacBook Pro in favor of USB-C like they were reportedly considering doing. Can you imagine having to carry two different dongles just to use a proper pair of headphones with their hardware? That would be enough to make me sell off all my Apple stock and declare them beleaguered again. :-)
The 50mm f/1.2 is a nice portrait lens, but the differences aren't the sort of thing that the average person is likely to appreciate, which makes it a bit of a specialty thing. Being able to zoom or change lenses to get additional reach, by contrast, isn't at all uncommon. The classic example I usually give when pointing out how much cell phones suck for photography is the parent wanting to take pictures of his/her kid's dance recital or piano recital or band concert or whatever:
And they shouldn't be doing that. It causes most intelligent people to assume that the number of people who actually care about the issue is approximately zero. If you don't care enough to actually write something, you probably don't care much about it.
Worse, it does more harm than good. The FCC process is not a vote. It's an opportunity to raise new points about why you think the commissioners are complete idiots. If you aren't raising new valid points, then all you're doing is increasing the noise floor relative and making it harder to find the actual signal—the new points that need to be addressed. Every time someone copies and pastes somebody else's letter, they're actually harming their own position by making it more likely that the useful content will get lost in the noise.
These advocacy and lobby groups that do this need to just go away. If they can't successfully convince people to learn about the issues and write their own letters, then they aren't contributing usefully to the process, and their 501(c)3 status is a waste of taxpayer dollars.
True, but I think you can safely assume that those copy-and-paste jobs are utterly irrelevant, because:
So whether the posters are bots or not, the posts are still noise. At best, they're uninformed people who have been swayed by an astroturfing campaign by their ISPs that encouraged them to copy and paste something without really understanding it, in which case their opinions are ill-informed and could turn on a dime if they became well-informed on the subject or if someone else screamed more loudly. At worst, they're programmatic bots paid for by ISPs, and they all represent the opinions of one or two actual people. Either way, they should be treated as the opinions of the one or two people who organized the campaign, because they're the only people who actually felt strongly enough to write down their opinions.
Not even close. A top-of-the-line DSLR from 10 years ago would be a Canon 1Ds Mk III. With a full-frame sensor at 21.1 megapixels, it wipes the floor with most smartphone cameras even if you don't factor in things like oh, I don't know, zoom lenses....
That would be the 95% of the population who have never used an actual camera, of course....
This is just smoke from the former CEO, trying to avoid prosecution.
FTFY.