Why is it there, then? If operator overloading is only useful for mathematical constructions, why not simply bake those things into the language and be done with it rather than provide operator overloading which can, amongst other things, also be used to build those libraries?
Building large math API's aren't a priority for language designers.
To do what you're saying, you sort of have to add the operator overloading ability anyway, use it to implement a large math API, and then make the compiler "magically" treat that one API as special. If I were designing a language, I would rather--for both stylistic and practical reasons--just make a thumbs up/down decision on the overloading feature and let the community/marketplace develop their own math libraries.
Note that the implementation of a mathematical concept can vary widely. A stock matrix implementation isn't going to be suitable for dealing with huge sparse arrays, for instance. Other implementations may want to use OpenCL/CUDA, decimal math, specific rounding policies... the list is endless.
As others have pointed, there is a large range of mathematical ideas to which standard operators apply. Moreover, new maths are being added all the time and it's not unfathomable to invent your own idea to deal with a specific problem domain. (I've done this in production code, for instance, to enable set-like behavior of time-series data that is highly specific to the industry I work in. To be fair, I decided against operator overloading in that particular situation, but it could have gone either way.)
These days, there's no real harm in providing the feature. Yeah, it was abused back when C++ was new, but developers got over that. When word processors were new, we all went silly and put 10+ different fonts into our documents, but you don't see that anymore either.
Is that because they were warned by Djikstra that it would be harmful to use it haphazardly?
Programmers are more used to structuring their code (using functions, modules, etc.) and using best practices (minimizing globals, separation of concerns, etc.). This was not so much the case in the late 60's. That, combined with the "goto stigma", means that average developers avoid goto usage and good developers know when it's worth it.
We saw a similar backlash with the concept of operator overloading. People abused it in C++, the Java designers overreacted and prohibited it, but most languages since then recognize that "yeah, operator overloading's really nice when you're building an API for mathematical constructs" (like complex numbers, quaternions, and matrices). So it's there in C#, Python, D, Rust, Scala, but (from the little I've seen) people seldom abuse it these days.
Bad marketing: make users feel guilty everytime they try to acquire your product, especially when you are just one of hundreds of derivatives of the same free product (viz. Ubuntu, Debian, and other Linux-based OS'es).
Good marketing: write a blog entry about some trivially controversial aspect of your product and get it posted to a major tech forum for Linux enthusiasts.
Most of the "modern" languages seem to have this addiction to overly verbose libraries and obscenely long syntax. Do we really need method names that could constitute a simple sentence?
Long names are fine and even valuable. The real gremlin is in overly-abstracted API's, code generators, verbose XML configuration files, and other tools/libraries that have sacrificed usability while pursuing long feature lists and total control over a particular problem domain.
It is, in a funny way, the opposite usability trajectory that Gnome and many others in the UX crowd followed when they went off and started zealously reducing features in the name of simplicity.
Personally, I think that the underlying design principles should be the same whether you're designing application interfaces to be used by the general public or whether you're designing API's to be used by developers: in both cases you're trying to take something complicated and make it simpler. Sure, add those new/advanced features when you can, but do so in a way that doesn't raise the learning curve for the most common use cases.
I think bitcoins are a great experiment in 'anarchy'. It goes to show that even a crappy government beats none at all.
Perhaps you would like to see a list of what really, really crappy government gets you. In country after country, peoples' entire life savings were eradicated by government printing presses. In Weimar Germany, banknotes were best used as firewood.
No. A textual description is all that's needed to convey what happened.
Does it serve a persuasive purpose?
Yes. It's a visceral and concrete illustration of the ruthlesness of $THING. (Where $THING can be substituted with whatever religion, racial group, ideology, or institution that serves your persuasive purpose. For Fox's audience, THING="Islam"; for an atheist it's THING="religion"; for a Shia muslim maybe it's THING="Sunnis".)
Should Fox be censored or penalized by the government?
Hell on. Fortunately, nobody's making this argument. Yay first amendment!
Did Fox help ISIS by publishing the video?
Counterterrorist Malcom Nance (the "Waterboarding is torture, period." guy) thinks so, but I'm not seeing a description of why. Perhaps it's a combination of morale boost and being able to exert fear-control over their own territory. Perhaps (as another slashdotter speculated) they want to provoke the West into military intervention in order to further galvanize the Islamic world against Western influence. On the other hand, gratuitous violence is generally a great way to undermine your own cause; it's hard to imagine the video winning them any friends.These are boy-apes, demonstrating dominance and waving their guns at the cosmos, thinking that they somehow matter.
Should Fox have self-censored themselves for the sake of civic duty?
Ah: that seems to be what the debate's really about, isn't it? Those who think Fox abandoned their civic duty long ago will be tempted to "yes". Those who think of Fox as "too liberal" will say "no". Those of us with a good selection of defense industry stocks in our portfolio will also say "no", while trying to stifle a sudden case of the giggles.
By any measure I know the U.S. is the most diplomatic nation on earth. [For instance, ] in terms of foreign AID.
Foreign aid is a vehicle for exerting influence: for instance, to open foreign markets to US exports. You'd be a fool to think there were no strings attached. It's logical (at least in terms of game theory) for the US to exploit it's influence to its advantage, and we certainty do: take, for instance, our strong-arming intellectual property laws into numerous countries. Those laws support US exports (which tend to be soft on tangible goods and heavy on services and content).
I'm not criticizing any of this BTW, just describing the ground in front of us. The concern arises where maybe we're consuming accumulated good will for short term gains. Obviously, ISIS is going to view us as the great satan no matter what we do. But there 7 billion other people out there, and our long term ability to shape the world rests in part on their perception of our government.
We are number one the UK is number 2 the rest aren't even in the same league.
The US drops to the bottom of the list once you account for GDP. To be fair, that doesn't account for military presence [which saves Europeans a bundle on defense spending], military intervention [when it's not, um, massively misguided], and the generosity of the American public itself (thru churches and humanitarian organizations).
I've found very few MDs who have any kind of listening skills. I've known some brilliant ones.
Yeah, I know what you mean. In talking to several doctors, I get the distinct feeling that I'm on the flip side of what happens when my mother-in-law has a computing problem: she hands me the computer and starts offering endless way-off-the-mark suggestions which I have to forcibly ignore while trying to concentrate on troubleshooting the real problem.
Being listened to makes us feel better (in pretty much any human situation, but especially when our health is on the line). However, we as patients are generally dumping a load of crap on the doc when it comes to listing a "constellations of symptoms". It takes great patience and integrity for a doctor to diligently listen through all of that verbage for the 1-in-a-million gem, and most docs don't have that sort of time.
I'm still learning how to use doctors effectively, and the best thing I've learned over the past few years is that... if you've got a disease that's poorly understood, find the docs who have the expertise on that condition. (And hope they aren't just pill-pushers, I guess.) My general internist thought I needed a pacemaker, the cardiologist controlled the worst symptoms with drugs, and the dysautonomic disease specialist knew what my problem was and established a treatment plan to fix it. Something that was a complete mystery to the first two doctors was a routine case for the third.
the total number of deaths related to nuclear power are still somewhere shy of 100,000. (in reality this number is probably closer to 50,000 but it's difficult to say exactly how many additional cases of cancer Chernobyl caused, with a range of between 4000 and 98,500). Coal mining alone averages 1,800 deaths a year, or 126,000 deaths over the past 70 years
While I agree with your general line of reasoning, these numbers look considerably worse when adjusted for deaths/MWh or YPPL/MWh.
In addition, 70 years may be too short of a time period for evaluation. AFAIK, nuclear plants aren't designed to withstand war, and we also haven't see that many plants retire.
waste of time to try to disallow x,y values for things like this. anyone here who spent a few weeks on even a simple arduino could do this remapping in an afternoon
(1) Your average user would not be able to implement this hack. Technical users would have to research/experiment/tinker and/or wait for other technical users to do the same and publish their results. This buys time (see point 2).
(2) It makes the drone maker look good and reduces the risk of kneejerk legislative responses.
(3) Anyone who modifies their device to do this will receive the blunt of the blame. Blame will be apportioned less to the manufacturer, the regulations, or the general concept of consumer drones and more to the individual. Instead of being portrayed as a drunken fool doing something dumb but ultimately harmless (like the guy in the recent White House incident), the media will portray them as a shady hacker with possible terrorist intentions.
(4) Prosecutors who want to hang the operator out to dry will probably find more legal hooks to do so, since the operator intentionally disabled a "security" feature.
(1), (2), (3), and (4) are all good things for the manufacturer, who's market lives or dies by legislative and regulatory edict. That makes this worth doing, even if there's a jillion ways of undoing it.
And do you suppose the bank's employees pay for the fraud out their own salaries? Of course not! The cost of fraud is paid by their honest customer's banking fees
The cost is paid for by some combination of shareholders, employees, customers, and insurers. You can't really say what that combination is. If you magically eliminated all ATM thefts/fraud, most of that benefit would go to either shareholders or top-level management. However, if the labor market were tight, that benefit might go to higher salaries for ordinary employees. Then again, if competition is fierce, the savings might be used to lower fees or pay higher dividends on interest-bearing accounts. Perhaps something more complex would happen, like hiring additional programmers so more work process could be automated, thereby resulting in layoffs for other personnel. All of these outcomes have more complicated second level effects, since they would ripple through the economy at large.
What you can say is that we as society pay at large, since the damage to the machine/building is a net loss for humanity, and the effort of participants (police, bank personnel, ATM designers, and even the burglars themselves) could have been better spent on their next best opportunity cost. (The one exception might be if these were subsistence burglars, in which case the overall cost to humanity can be harder to calculate.)
ISPs can no longer use false advertisement to try and trick ill-informed consumers (ie. grandma) into paying for garbage.
Easily solved:
BUY NOW!! Super-fast-ultra-speed internet** is available in your area!!
**Up to 1Mbps or beyond!
(And oh yeah, we'll still hijack DNS NXDomain responses, throttle Netflix/bittorrent, keep connectivity records, and spy on your traffic w/o a warrant.)
Do they? Do you have data to back this up, or are you just guessing? Because from where I'm sitting, it looks a lot like the hardest security problems are the features you expose to users.
If you don't have to have any features, then yes, you can make your software very, very secure.:-)
The CWE publishes a list of the Top 25 Most Dangerous Software Errors which aims to "list of the most widespread and critical errors that can lead to serious vulnerabilities". You'll notice CERT tags their vulnerability announcements with references to the CWE when applicable.
Most are language-independent.... no surprise to see CWE-89 (SQL injection) and CWE-78 (command line injection) in there, as well as the slough of crypto/authN/authZ-related stuff. But where are the language-dependent bugs coming from? If you drill down on the code examples for CWE-120, -131, -134, and -676, you'll see C and C++ are a re-occurring theme.
You contradict yourself at the end of the paragraph and try to come up with a reasonable substitute.
No contradictions... knowing how stuff work is a training/educational goal (for programmers and those who teach them). Not having to know how stuff works is a design goal (for language creators, API writers, and designers in general). The former gives you insight, the latter gives you leverage.
Hey, if your point is that too many PHB's and programmers think "managed" is a cure-all, I won't stand in your way. What I'm saying is that managed is a huge win for security.
The hardest security problems to solve aren't the overflows, it's the features given to users.
By contrast, the most common security problems are any situation where you silently expect the programmer to manually preserve some invariant (e.g, never allocate memory without a plan to deallocate it, never deallocate if anything else holds a pointer to it, never write to a buffer without checking bounds, etc.). Managed languages eliminate C/C++'s largest (and most critical) attack surface.
Now sure, I agree that they don't eliminate all attack surfaces. Security is hard. Java/C# have their own "manual invariants", such as always escaping/parameterizing SQL. ASP.NET Forms have a nightmarish arrangement where some controls/properties auto-escape HTML and others don't. Crypto primitives are widely available but poorly explained. Multi-threading is a minefield. But even here, the industry can eliminate the widest number of security issues using secure-by-default design. In C# for instance, EF/Razor/TPL make it (1) easier to accomplish programmer intent while also (2) making it harder to break low-level invariants.
Think of VB macro viruses, that spread wildly in a managed language. Wordpress is another example of software written in a managed language with tons of exploits.
Office macros and PHP are some of the most hilariously bad designs in computing history. By necessity, any programming language worth its salt will let you make farcically bad decisions.
Notice (for example) his micro-agressions against people who understand garbage collection. The implication is you don't need to think about it, C# will take care of memory.......which if you take seriously, means you'll be leaking crap all over the place and someone like me will have to come clean it up for you.
As a Google developer, he can probably just throw clusters of auto-recycling web servers at the problem. Aside from opening avenues for DOS attacks, the consequences of this sort of problem (e.g., not knowing how your GC works) have more to do with performance/reliability than security (albeit the 3 are intimately linked).
Something we can probably both agrees on is that there's no substitute for knowing how things work. However, the reality is that most programmers don't care and even those who do have a limited mental budget for complexity. So there's also no substitute for being able to eliminate sources of complexity that are ancillary to the task at hand.
People who think that Java (or C#, or Python) language will fix their security problems write more security bugs than C programmers who work around the weaknesses of their language.
Apparently, your experienced C developer is still leaving holes for arbitrary execution, despite all of the tools (fuzzing/NX/ASLR) targeting this specific issue. Managed languages (like Java and C#) give you a "secure-by-default" memory and execution model that's a lot harder to accidentally mess up. The more "stuff" (languages, libraries, operating systems, etc.) that's secure-by-default, the less security holes we will have.
So, you have no issues with people recording you when you don't know about it?
Remember how cellular "feature phones" used to make an audible "ker-click" sound when you took a picture, and there was no option to turn it off? And how the gym prohibited all cameras in the locker room? Folks were worried about these increasingly ubiquitous cameras. Then smartphones came along and the cameras truly were ubiquitous and everyone sort of gave up... you can turn off the fake shutter sound now and that man in the corner staring down at his cellphone probably isn't trying to take a perv shot of you (probably).
I'm not defending Google here, or arguing that Glass is a good thing. Rather, that it's possible Glass will become socially acceptable once people get over the novelty of it. If I were advising Google, I'd tell them to add a prominent LED to the front of the Glass that glowed red when the camera was being used. Then people would "know" if you were recording or not.
The drawback, of course, is that this negatively impacts augmented reality (AR) applications, which are one of the big promises of Glass-like devices. In AR, the images are analyzed to detect faces/landmarks/surfaces/whatever in order to draw reminders/factoids/whatever in the user's field of vision. For instance, maybe Glass could be showing a mechanic the relevant portion of the service manual when he stares at $VEHICLEPART. Google could make it so that the LED doesn't light up when the camera is being used for non-recording purposes. The drawback to that is that Glass is then just one software hack away from being able to record covertly (e.g., without lighting up the public-notification LED)... so it'd really be better to stick with the first approach and hardwire the LED to the camera sensor.
Of course, you're still being recorded/tracked by a panopoly of public CCTV's, license plate readers, websites, and various other data cabals.
My original lack of understand on what D really offers remains. Responses like "high-performance applications" tend to flow over my [head].
As a C programmer, you maybe haven't bought into OOP, templates, exception handling, metaprogramming, or other such features that C++ brought to the systems programming scene. Maybe, like Linus Torvalds, you've tried C++ and think it's a horrible language.
I myself agree with you (or rather, Linus)... except I'm coming from the applications world (C# mainly), where those nice features (that C++ popularized well and implemented poorly) are bread-and-butter techniques. I want to do systems programming with objects, exceptions, namespaces, reflection, etc., *but* I'm not willing to weather C++ for them, nor am I willing to drop down to C. Ergo D, except it doesn't really have a viable ecosystem at this point.:-( (And, like you said, JavaScript/Java/C#/Python/etc are fast enough for the vast majority of applications.)
I never understood what D offered that wasn't offered elsewhere.
Mainly, it's a systems programming language, meaning that it gives the programmer fine-grained control over memory and operations so that you can write operating systems, drivers, and high-performance applications. This is relevant because, aside from the two biggies (C and C++), there aren't a lot of other languages in this space. I mean, there's Objective-C (which sort of half-asses it), and recently Go and Rust arrived on the scene. All the other popular languages are pretty much for scripting (Python, JavaScript, PHP, etc.), or running atop a managed virtual machine (Java and C#).
As for what it offers... it's basically a re-invention of C++. No, no... it's deeper than that. It's the idea of C++ re-invented in such a way that you get most all the power and low-level control of C++ without so many of the dangers and difficulties.
Unfortunately, D has struggled to gain wider acceptance. It fractured it's community when D version 2 broke backwards compatibility with D version 1, and the forums (which run on a dedicated Usenet server, FFS) are filled with endless commentary about what does and doesn't work in the latest point release of the DMD compiler. Bright and Alexandrescu have certainly designed a compelling language, but they seem (from my distant vantage point) to be mired in implementation details... yeah there's a standard library and everything, but the surrounding ecosystem (standards, tutorials, tools, IDE's, API's, packaging, etc.) hasn't made the leap to that sort of functional minimum you see with (for instance) node.js or Haskell's "batteries included" experience.
TL;DR - D's a super awesome low-level language, but it's not yet a platform.
I'm not sure it would be a bad thing for OSHA to require employers to provide adjustable desks for office workers.
Check that make-a-law impulse. A desk job is just about the safest thing you can do (assuming you don't have to travel for work). Very little chance of suffocating a mile underground (mining), disappearing into the sea (commercial fishing), losing a limb (logging, mill works), or routine exposure to carcinogens (many factory jobs). (Obligatory slideshow: the twenty deadliest jobs.)
That's not to say OSHA should have no concern but office workers (whichtheydo)... just that it should be proportional to the risk involved.
Do you know of any articles that back up your claim?
Read this brief on the perils of both sitting and standing, and then check the references at the bottom. Notably, standing all day leads to varicose veins and puts a strain on your circulatory system.
Just generally, the factory production line taught us long ago that holding the same pose or making the same motions all day long will have chronic repercussions. (If you ever have to work an assembly line, hope it's in a factory that practices job rotation so your tasks are varied over time.)
Amazing that/.'ers assail governments who are trying to protect them from terrorists and then turn a blind eye to Facebook, Google, Yahoo.
If we're going to stick to simple arguments: governments kill more people than terrorists; ergo, they are the greater threat.
Of course, if you want a more sophisticated argument, then you need to go back to democratic principles. Separation of powers, checks and balances, due process, and so forth. It's always about power and preventing too much of it from pooling in one place. No matter how noble government objectives are at the current moment (which you seem to have some charmingly naive assumptions about), you don't want to setup bad power structures or the next thing you know some low-level spook will be defacto dictator of your republic.
Alternately, you could point out that all this spying and intrusion on civil liberties is an enormous waste of money. The government could save wayyyyy more lives by focusing on cancer, heart disease, and vehicular deaths. Heck, poisonings are the second leading cause of accidental deaths, but nobody's insisting the government watch you take your meds or make you lock up your cleaning supplies.
And I don't know what you mean about slashdotters turning a blind eye to Facebook and Google... we bitch about that all the time too.
By definition, no communication using a 3rd party as an intermediary has ever been totally secure.
But with strong crypto it's secure enough that the 3rd party can see (or alter) your communications. Obama and Cameron and (undoubtedly) all other future leaders want to strip away this protection using the force of law to change how crypto products are designed. You will live your life under the state microscope and, as always, the proper prerogatives of government will be twisted to cover up incompetence and serve the powerful few instead of protecting the dignity of the individual.
your idealogy is FALSE and that you blindly and sheepishly support a failed system
All ideologies are false. That's what makes them so tasty. We crave simple rules and easy answers for this complex, interwoven world of ours. And once we subscribe to a set of Answers, we can confidently stride them out upon others... especially those weaker souls who may want to look at an issue from multiple angles and acknowledge the inherent difficulties of society's seemingly numerous and intractable problems. There's nothing better than feeling intellectually invulnerable and knowing that all voices that run in any way counter to your own are automatically corrupt or incompetent, dismissible out of hand without even having to listen to them. The world is so clear when righteousness runs thru your veins.
Whatever the source--left or right, extremist or complacent--unchecked ideology is the true enemy of humanity.
(Yah, I know... don't feed the trolls, but I've been where AC is, and it is a trap unto itself.)
Slashdot Mirror
Why is it there, then? If operator overloading is only useful for mathematical constructions, why not simply bake those things into the language and be done with it rather than provide operator overloading which can, amongst other things, also be used to build those libraries?
Is that because they were warned by Djikstra that it would be harmful to use it haphazardly?
Programmers are more used to structuring their code (using functions, modules, etc.) and using best practices (minimizing globals, separation of concerns, etc.). This was not so much the case in the late 60's. That, combined with the "goto stigma", means that average developers avoid goto usage and good developers know when it's worth it.
We saw a similar backlash with the concept of operator overloading. People abused it in C++, the Java designers overreacted and prohibited it, but most languages since then recognize that "yeah, operator overloading's really nice when you're building an API for mathematical constructs" (like complex numbers, quaternions, and matrices). So it's there in C#, Python, D, Rust, Scala, but (from the little I've seen) people seldom abuse it these days.
Came looking for Gamergate fodder; left disappointed. :-(
Bad marketing: make users feel guilty everytime they try to acquire your product, especially when you are just one of hundreds of derivatives of the same free product (viz. Ubuntu, Debian, and other Linux-based OS'es).
Good marketing: write a blog entry about some trivially controversial aspect of your product and get it posted to a major tech forum for Linux enthusiasts.
Most of the "modern" languages seem to have this addiction to overly verbose libraries and obscenely long syntax. Do we really need method names that could constitute a simple sentence?
Long names are fine and even valuable. The real gremlin is in overly-abstracted API's, code generators, verbose XML configuration files, and other tools/libraries that have sacrificed usability while pursuing long feature lists and total control over a particular problem domain.
It is, in a funny way, the opposite usability trajectory that Gnome and many others in the UX crowd followed when they went off and started zealously reducing features in the name of simplicity.
Personally, I think that the underlying design principles should be the same whether you're designing application interfaces to be used by the general public or whether you're designing API's to be used by developers: in both cases you're trying to take something complicated and make it simpler. Sure, add those new/advanced features when you can, but do so in a way that doesn't raise the learning curve for the most common use cases.
I think bitcoins are a great experiment in 'anarchy'. It goes to show that even a crappy government beats none at all.
Perhaps you would like to see a list of what really, really crappy government gets you. In country after country, peoples' entire life savings were eradicated by government printing presses. In Weimar Germany, banknotes were best used as firewood.
Does it serve a journalistic purpose?
No. A textual description is all that's needed to convey what happened.
Does it serve a persuasive purpose?
Yes. It's a visceral and concrete illustration of the ruthlesness of $THING. (Where $THING can be substituted with whatever religion, racial group, ideology, or institution that serves your persuasive purpose. For Fox's audience, THING="Islam"; for an atheist it's THING="religion"; for a Shia muslim maybe it's THING="Sunnis".)
Should Fox be censored or penalized by the government?
Hell on. Fortunately, nobody's making this argument. Yay first amendment!
Did Fox help ISIS by publishing the video?
Counterterrorist Malcom Nance (the "Waterboarding is torture, period." guy) thinks so, but I'm not seeing a description of why. Perhaps it's a combination of morale boost and being able to exert fear-control over their own territory. Perhaps (as another slashdotter speculated) they want to provoke the West into military intervention in order to further galvanize the Islamic world against Western influence. On the other hand, gratuitous violence is generally a great way to undermine your own cause; it's hard to imagine the video winning them any friends.These are boy-apes, demonstrating dominance and waving their guns at the cosmos, thinking that they somehow matter.
Should Fox have self-censored themselves for the sake of civic duty?
Ah: that seems to be what the debate's really about, isn't it? Those who think Fox abandoned their civic duty long ago will be tempted to "yes". Those who think of Fox as "too liberal" will say "no". Those of us with a good selection of defense industry stocks in our portfolio will also say "no", while trying to stifle a sudden case of the giggles.
By any measure I know the U.S. is the most diplomatic nation on earth. [For instance, ] in terms of foreign AID.
Foreign aid is a vehicle for exerting influence: for instance, to open foreign markets to US exports. You'd be a fool to think there were no strings attached. It's logical (at least in terms of game theory) for the US to exploit it's influence to its advantage, and we certainty do: take, for instance, our strong-arming intellectual property laws into numerous countries. Those laws support US exports (which tend to be soft on tangible goods and heavy on services and content).
I'm not criticizing any of this BTW, just describing the ground in front of us. The concern arises where maybe we're consuming accumulated good will for short term gains. Obviously, ISIS is going to view us as the great satan no matter what we do. But there 7 billion other people out there, and our long term ability to shape the world rests in part on their perception of our government.
We are number one the UK is number 2 the rest aren't even in the same league.
The US drops to the bottom of the list once you account for GDP. To be fair, that doesn't account for military presence [which saves Europeans a bundle on defense spending], military intervention [when it's not, um, massively misguided], and the generosity of the American public itself (thru churches and humanitarian organizations).
I've found very few MDs who have any kind of listening skills. I've known some brilliant ones.
Yeah, I know what you mean. In talking to several doctors, I get the distinct feeling that I'm on the flip side of what happens when my mother-in-law has a computing problem: she hands me the computer and starts offering endless way-off-the-mark suggestions which I have to forcibly ignore while trying to concentrate on troubleshooting the real problem.
Being listened to makes us feel better (in pretty much any human situation, but especially when our health is on the line). However, we as patients are generally dumping a load of crap on the doc when it comes to listing a "constellations of symptoms". It takes great patience and integrity for a doctor to diligently listen through all of that verbage for the 1-in-a-million gem, and most docs don't have that sort of time.
I'm still learning how to use doctors effectively, and the best thing I've learned over the past few years is that... if you've got a disease that's poorly understood, find the docs who have the expertise on that condition. (And hope they aren't just pill-pushers, I guess.) My general internist thought I needed a pacemaker, the cardiologist controlled the worst symptoms with drugs, and the dysautonomic disease specialist knew what my problem was and established a treatment plan to fix it. Something that was a complete mystery to the first two doctors was a routine case for the third.
the total number of deaths related to nuclear power are still somewhere shy of 100,000. (in reality this number is probably closer to 50,000 but it's difficult to say exactly how many additional cases of cancer Chernobyl caused, with a range of between 4000 and 98,500). Coal mining alone averages 1,800 deaths a year, or 126,000 deaths over the past 70 years
While I agree with your general line of reasoning, these numbers look considerably worse when adjusted for deaths/MWh or YPPL/MWh.
In addition, 70 years may be too short of a time period for evaluation. AFAIK, nuclear plants aren't designed to withstand war, and we also haven't see that many plants retire.
waste of time to try to disallow x,y values for things like this. anyone here who spent a few weeks on even a simple arduino could do this remapping in an afternoon
(1) Your average user would not be able to implement this hack. Technical users would have to research/experiment/tinker and/or wait for other technical users to do the same and publish their results. This buys time (see point 2).
(2) It makes the drone maker look good and reduces the risk of kneejerk legislative responses.
(3) Anyone who modifies their device to do this will receive the blunt of the blame. Blame will be apportioned less to the manufacturer, the regulations, or the general concept of consumer drones and more to the individual. Instead of being portrayed as a drunken fool doing something dumb but ultimately harmless (like the guy in the recent White House incident), the media will portray them as a shady hacker with possible terrorist intentions.
(4) Prosecutors who want to hang the operator out to dry will probably find more legal hooks to do so, since the operator intentionally disabled a "security" feature.
(1), (2), (3), and (4) are all good things for the manufacturer, who's market lives or dies by legislative and regulatory edict. That makes this worth doing, even if there's a jillion ways of undoing it.
And do you suppose the bank's employees pay for the fraud out their own salaries? Of course not! The cost of fraud is paid by their honest customer's banking fees
The cost is paid for by some combination of shareholders, employees, customers, and insurers. You can't really say what that combination is. If you magically eliminated all ATM thefts/fraud, most of that benefit would go to either shareholders or top-level management. However, if the labor market were tight, that benefit might go to higher salaries for ordinary employees. Then again, if competition is fierce, the savings might be used to lower fees or pay higher dividends on interest-bearing accounts. Perhaps something more complex would happen, like hiring additional programmers so more work process could be automated, thereby resulting in layoffs for other personnel. All of these outcomes have more complicated second level effects, since they would ripple through the economy at large.
What you can say is that we as society pay at large, since the damage to the machine/building is a net loss for humanity, and the effort of participants (police, bank personnel, ATM designers, and even the burglars themselves) could have been better spent on their next best opportunity cost. (The one exception might be if these were subsistence burglars, in which case the overall cost to humanity can be harder to calculate.)
ISPs can no longer use false advertisement to try and trick ill-informed consumers (ie. grandma) into paying for garbage.
Easily solved:
BUY NOW!! Super-fast-ultra-speed internet** is available in your area!!
**Up to 1Mbps or beyond!
(And oh yeah, we'll still hijack DNS NXDomain responses, throttle Netflix/bittorrent, keep connectivity records, and spy on your traffic w/o a warrant.)
Time travel is possible but not in the way you think about it. It exists going backwards but is tied to alternate realities...
I see someone read Anathem.
Do they? Do you have data to back this up, or are you just guessing? Because from where I'm sitting, it looks a lot like the hardest security problems are the features you expose to users.
If you don't have to have any features, then yes, you can make your software very, very secure. :-)
The CWE publishes a list of the Top 25 Most Dangerous Software Errors which aims to "list of the most widespread and critical errors that can lead to serious vulnerabilities". You'll notice CERT tags their vulnerability announcements with references to the CWE when applicable.
Most are language-independent.... no surprise to see CWE-89 (SQL injection) and CWE-78 (command line injection) in there, as well as the slough of crypto/authN/authZ-related stuff. But where are the language-dependent bugs coming from? If you drill down on the code examples for CWE-120, -131, -134, and -676, you'll see C and C++ are a re-occurring theme.
You contradict yourself at the end of the paragraph and try to come up with a reasonable substitute.
No contradictions... knowing how stuff work is a training/educational goal (for programmers and those who teach them). Not having to know how stuff works is a design goal (for language creators, API writers, and designers in general). The former gives you insight, the latter gives you leverage.
Hey, if your point is that too many PHB's and programmers think "managed" is a cure-all, I won't stand in your way. What I'm saying is that managed is a huge win for security.
The hardest security problems to solve aren't the overflows, it's the features given to users.
By contrast, the most common security problems are any situation where you silently expect the programmer to manually preserve some invariant (e.g, never allocate memory without a plan to deallocate it, never deallocate if anything else holds a pointer to it, never write to a buffer without checking bounds, etc.). Managed languages eliminate C/C++'s largest (and most critical) attack surface.
Now sure, I agree that they don't eliminate all attack surfaces. Security is hard. Java/C# have their own "manual invariants", such as always escaping/parameterizing SQL. ASP.NET Forms have a nightmarish arrangement where some controls/properties auto-escape HTML and others don't. Crypto primitives are widely available but poorly explained. Multi-threading is a minefield. But even here, the industry can eliminate the widest number of security issues using secure-by-default design. In C# for instance, EF/Razor/TPL make it (1) easier to accomplish programmer intent while also (2) making it harder to break low-level invariants.
Think of VB macro viruses, that spread wildly in a managed language. Wordpress is another example of software written in a managed language with tons of exploits.
Office macros and PHP are some of the most hilariously bad designs in computing history. By necessity, any programming language worth its salt will let you make farcically bad decisions.
Notice (for example) his micro-agressions against people who understand garbage collection. The implication is you don't need to think about it, C# will take care of memory.......which if you take seriously, means you'll be leaking crap all over the place and someone like me will have to come clean it up for you.
As a Google developer, he can probably just throw clusters of auto-recycling web servers at the problem. Aside from opening avenues for DOS attacks, the consequences of this sort of problem (e.g., not knowing how your GC works) have more to do with performance/reliability than security (albeit the 3 are intimately linked).
Something we can probably both agrees on is that there's no substitute for knowing how things work. However, the reality is that most programmers don't care and even those who do have a limited mental budget for complexity. So there's also no substitute for being able to eliminate sources of complexity that are ancillary to the task at hand.
People who think that Java (or C#, or Python) language will fix their security problems write more security bugs than C programmers who work around the weaknesses of their language.
Apparently, your experienced C developer is still leaving holes for arbitrary execution, despite all of the tools (fuzzing/NX/ASLR) targeting this specific issue. Managed languages (like Java and C#) give you a "secure-by-default" memory and execution model that's a lot harder to accidentally mess up. The more "stuff" (languages, libraries, operating systems, etc.) that's secure-by-default, the less security holes we will have.
So, you have no issues with people recording you when you don't know about it?
Remember how cellular "feature phones" used to make an audible "ker-click" sound when you took a picture, and there was no option to turn it off? And how the gym prohibited all cameras in the locker room? Folks were worried about these increasingly ubiquitous cameras. Then smartphones came along and the cameras truly were ubiquitous and everyone sort of gave up... you can turn off the fake shutter sound now and that man in the corner staring down at his cellphone probably isn't trying to take a perv shot of you (probably).
I'm not defending Google here, or arguing that Glass is a good thing. Rather, that it's possible Glass will become socially acceptable once people get over the novelty of it. If I were advising Google, I'd tell them to add a prominent LED to the front of the Glass that glowed red when the camera was being used. Then people would "know" if you were recording or not.
The drawback, of course, is that this negatively impacts augmented reality (AR) applications, which are one of the big promises of Glass-like devices. In AR, the images are analyzed to detect faces/landmarks/surfaces/whatever in order to draw reminders/factoids/whatever in the user's field of vision. For instance, maybe Glass could be showing a mechanic the relevant portion of the service manual when he stares at $VEHICLEPART. Google could make it so that the LED doesn't light up when the camera is being used for non-recording purposes. The drawback to that is that Glass is then just one software hack away from being able to record covertly (e.g., without lighting up the public-notification LED)... so it'd really be better to stick with the first approach and hardwire the LED to the camera sensor.
Of course, you're still being recorded/tracked by a panopoly of public CCTV's, license plate readers, websites, and various other data cabals.
My original lack of understand on what D really offers remains. Responses like "high-performance applications" tend to flow over my [head].
As a C programmer, you maybe haven't bought into OOP, templates, exception handling, metaprogramming, or other such features that C++ brought to the systems programming scene. Maybe, like Linus Torvalds, you've tried C++ and think it's a horrible language.
I myself agree with you (or rather, Linus)... except I'm coming from the applications world (C# mainly), where those nice features (that C++ popularized well and implemented poorly) are bread-and-butter techniques. I want to do systems programming with objects, exceptions, namespaces, reflection, etc., *but* I'm not willing to weather C++ for them, nor am I willing to drop down to C. Ergo D, except it doesn't really have a viable ecosystem at this point. :-( (And, like you said, JavaScript/Java/C#/Python/etc are fast enough for the vast majority of applications.)
I never understood what D offered that wasn't offered elsewhere.
Mainly, it's a systems programming language, meaning that it gives the programmer fine-grained control over memory and operations so that you can write operating systems, drivers, and high-performance applications. This is relevant because, aside from the two biggies (C and C++), there aren't a lot of other languages in this space. I mean, there's Objective-C (which sort of half-asses it), and recently Go and Rust arrived on the scene. All the other popular languages are pretty much for scripting (Python, JavaScript, PHP, etc.), or running atop a managed virtual machine (Java and C#).
As for what it offers... it's basically a re-invention of C++. No, no... it's deeper than that. It's the idea of C++ re-invented in such a way that you get most all the power and low-level control of C++ without so many of the dangers and difficulties.
Unfortunately, D has struggled to gain wider acceptance. It fractured it's community when D version 2 broke backwards compatibility with D version 1, and the forums (which run on a dedicated Usenet server, FFS) are filled with endless commentary about what does and doesn't work in the latest point release of the DMD compiler. Bright and Alexandrescu have certainly designed a compelling language, but they seem (from my distant vantage point) to be mired in implementation details... yeah there's a standard library and everything, but the surrounding ecosystem (standards, tutorials, tools, IDE's, API's, packaging, etc.) hasn't made the leap to that sort of functional minimum you see with (for instance) node.js or Haskell's "batteries included" experience.
TL;DR - D's a super awesome low-level language, but it's not yet a platform.
I'm not sure it would be a bad thing for OSHA to require employers to provide adjustable desks for office workers.
Check that make-a-law impulse. A desk job is just about the safest thing you can do (assuming you don't have to travel for work). Very little chance of suffocating a mile underground (mining), disappearing into the sea (commercial fishing), losing a limb (logging, mill works), or routine exposure to carcinogens (many factory jobs). (Obligatory slideshow: the twenty deadliest jobs.)
That's not to say OSHA should have no concern but office workers (which they do)... just that it should be proportional to the risk involved.
Do you know of any articles that back up your claim?
Read this brief on the perils of both sitting and standing, and then check the references at the bottom. Notably, standing all day leads to varicose veins and puts a strain on your circulatory system.
Just generally, the factory production line taught us long ago that holding the same pose or making the same motions all day long will have chronic repercussions. (If you ever have to work an assembly line, hope it's in a factory that practices job rotation so your tasks are varied over time.)
Amazing that /.'ers assail governments who are trying to protect them from terrorists and then turn a blind eye to Facebook, Google, Yahoo.
If we're going to stick to simple arguments: governments kill more people than terrorists; ergo, they are the greater threat.
Of course, if you want a more sophisticated argument, then you need to go back to democratic principles. Separation of powers, checks and balances, due process, and so forth. It's always about power and preventing too much of it from pooling in one place. No matter how noble government objectives are at the current moment (which you seem to have some charmingly naive assumptions about), you don't want to setup bad power structures or the next thing you know some low-level spook will be defacto dictator of your republic.
Alternately, you could point out that all this spying and intrusion on civil liberties is an enormous waste of money. The government could save wayyyyy more lives by focusing on cancer, heart disease, and vehicular deaths. Heck, poisonings are the second leading cause of accidental deaths, but nobody's insisting the government watch you take your meds or make you lock up your cleaning supplies.
And I don't know what you mean about slashdotters turning a blind eye to Facebook and Google... we bitch about that all the time too.
By definition, no communication using a 3rd party as an intermediary has ever been totally secure.
But with strong crypto it's secure enough that the 3rd party can see (or alter) your communications. Obama and Cameron and (undoubtedly) all other future leaders want to strip away this protection using the force of law to change how crypto products are designed. You will live your life under the state microscope and, as always, the proper prerogatives of government will be twisted to cover up incompetence and serve the powerful few instead of protecting the dignity of the individual.
your idealogy is FALSE and that you blindly and sheepishly support a failed system
All ideologies are false. That's what makes them so tasty. We crave simple rules and easy answers for this complex, interwoven world of ours. And once we subscribe to a set of Answers, we can confidently stride them out upon others... especially those weaker souls who may want to look at an issue from multiple angles and acknowledge the inherent difficulties of society's seemingly numerous and intractable problems. There's nothing better than feeling intellectually invulnerable and knowing that all voices that run in any way counter to your own are automatically corrupt or incompetent, dismissible out of hand without even having to listen to them. The world is so clear when righteousness runs thru your veins.
Whatever the source--left or right, extremist or complacent-- unchecked ideology is the true enemy of humanity .
(Yah, I know... don't feed the trolls, but I've been where AC is, and it is a trap unto itself.)