I think that it's more protective of citizens to behave in a way that isn't morally reprehensible.
That's an excellent and underappreciated point. The only difference between a morally reprehensible government-sanctioned action against a terrorist, and an action against you is an easily manufactured excuse. If morally reprehensible actions were never permitted, then the citizens need never fear their own government, which was the whole point of the constitution to begin with.
you can separate them and ask them questions then torture them when their answers don't match.
Except that doesn't work, because people being tortured will say anything to make it stop. At no point when they change their stories can you be certain they're now telling the truth. Even if their stories suddenly match, it could be a complete fluke, or as a result of the interrogator asking leading questions. Torture is useless.
One curious corollary is that if the human brain is a Turing machine, then humans can never decide this issue either, a point that the authors deliberately steer well clear of.
It's not curious at all. The goal was to determine if a computer can decide with certainty whether another agent intends to do harm. This is obviously unsolvable, even for humans. Of course, we don't require humans to be absolutely certain in all cases before pulling the trigger, we just expect reasonable belief that oneself or others are in danger (for a self-defence argument). Reasonable belief is even easier to decide for computers, since the internal states resulting in that conclusion are fully available to us (unlike the human mind).
When Debian pushed Gnome3 and the community didn't like it [...] Now there is the systemd debacle. A large number of people have voiced their disapproval [...]
You seem to be speaking for "the community", but I don't see any hard numbers suggesting that the majority of said community actually shares your opinions. Just because many voices cry out and cry loudly, does not make those voices representative of anything meaningful.
While they do have the necessary language support for functional programming, the fact that they are impure means that even when you're following the functional paradigm you can't count on the rest of the program playing by the same rules. Any call to external code may perform I/O or depend on or modify global mutable state.
Sure, but triggering side-effects during a fold can be perfectly sensible, and this doesn't make functional programming languages any less functional. Find me one person that considers this program to be non-functional, as your definition does:
let main = let list = [10; 2; 99; 30; 3] in
map (fun x -> printf "%d\r\n" x);;
and that your resources are freed deterministically the instant you are done with them, rather than "at some time in the future, maybe".
Except this can lead to extremely high latency due to cascading deletions, which is another potential source of performance problems in C/C++. If you try to bound the amount of work to do to avoid this problem, you necessarily introduce reclamation latency. Reclamation latency isn't necessarily a bad thing.
If you use smart pointers to manage your dynamic allocations, you'll find that memory management in C++ isn't any harder than in a garbage-collected language.
Because smart pointers are degenerate garbage collection.
Having closures does not make a functional language, instead, what makes a functional language is referential transparency.
Scheme, Lisp, OCaml are all functional languages that are not referentially transparent. Pure functional languages require referential transparency, but impure functional languages do exist.
JavaScript is a functional language, but it's also procedural and object-oriented.
C/C++ certainly let you shoot yourself in the foot regarding correctness, but they generally don't make it easy to shoot yourself in the foot regarding performance.
Sure they do, you're less likely to go through the hassle of creating a data structure that would be optimal for your domain simply because of the complicated memory management issues it raises. This is a complete non-issue with GC'd languages, so you're far more likely to do the (asymptotically) right thing.
More people means more risk, more risk means more cost, that cost is distributed among the group by taking more of their income.
More people does not necessarily mean more risk. More people can in fact, and often does, mean less risk.
Ergo, more income is being redistributed. So although you are technically correct in your statement about causality; in the context of this scenario your statement is wrong.
Income redistribution plans apply to everyone. Obamacare applies only to those who get health insurance. Therefore, it's not an income redistribution plan.
Obamacare is an income redistribution plan the way having a job is a coffee cup redistribution plan. Just because A can cause B, does not entail that A is a B in the sense you are implying.
That aside, will people please stop this constant masturbation about startup times? There are way, way, way more important things to deal with than edging out a few more seconds. Systemd provides me with no perceivable gains.
Since you argue about systemd from a user's perspective, then your own argument implies that you shouldn't care at all what sort of init system is in place, so why be against systemd? Given your view, it's purely a distribution's choice what init system to use because it's largely invisible to the user.
For those of us living in the US (as in most democracies), I think most of the time they coincide reasonably well.
I doubt that very much. Most likely many of the ridiculous laws on the books are not enforced (like laws on sexual position), but that's not the same as what's illegal being roughly synonymous with what's wrong. It's a much repeated claim that pretty much everyone breaks some law at least once per day in the US.
Good luck starting a security company with the slogan "We provide 90% security!"
I don't know what you're talking about. If anything, that would be "90% fewer security vulnerabilities", which sounds like perfectly good marketing.
I do use Haskell myself for certain things, and I can tell you it's no problem creating insecure applications in Haskell.
I never said Haskell was the perfect language, just that it provides good examples of achieving the needed safety properties, in that it can be extended to verify many properties that may be of interest. I didn't define "safe" in my original post, as the requried "safety" properties are domain-specific. Memory safety is the minimum needed, which would automatically handle one of the most common vulnerabilities in single programs (buffer overflows). A language that can be used to specify and check the required properties is a "safe" language for a given domain. Many languages fit most problems, few languages may be safe for all problems (although possibly undesirable for other reasons).
If all we had were Haskell's DoS vulnerabilities, we would be in a much better place.
Most exploits are due to human errors they could have done in any language
Not a chance. Here's a list of the top 25 exploits from 2011. From this list, numbers 3 and 20 would have been solved right away by using any memory safe language. Most memory safe languages also implement overflow checking, so that's 24 off too.
Languages featuring parametric polymorphism can tag unsafe values received as user inputs, so you can easily solve vulnerabilities 1, 2, 10, 14, 22, and 23 (all you really need is parametric polymorphism -- I've even done this in C#).
The crypto entries can be handled with session types that expect encrypted packets, not plaintext. Even the selection of appropriate crypto algorithm can be constrained by various parameters and checked at compile-time, ie. a Haskell type class constraint could specify a whitelist of unbroken crypto algorithms for unrestricted use, and those which are only good in restricted scenarios.
Design by contract can handle precondition violations, ie. #18, and such contracts can be statically checked these days in Haskell, C# and Ada.
A capability-secure language would handle the rest (mainly "porous defense" category remains). Few languages implement full capability security properties, and they remain vulnerable to the extent that they violate those principles.
The point is that the needed safety properties to address most common security vulnerabilities have been known for decades. Capability security was invented in the 1960s, and memory safety has been available since the first Lisp. Unfortunately, many programmers aren't interested in safety properties because they're focused too much on raw speed, but don't want to spend the verification effort to use that speed safely (Frama-C or Ada), or they want to avoid all verification effort period (dynamically typed languages).
And that you know of. The problem is that you do not know everything.
No, that's not how it works. You don't outlaw all possible bad behaviours, you enable only the behaviours you want to achieve the features you need. Everything is is forbidden statically.
My point is that you can't depend on the language to protect you. I'm not saying you should ignore good technology choices because you know better than those crazy compiler people. But I do not believe that it is possible to create something that is completely unhackable.
With a theorem prover like Coq, you can statically check any property you want. So you'll have to more precisely define "unhackable" before "it is impossible to create something that is completely unhackable" can have a truth value.
If used extensively, the only bugs you can introduce with a theorem prover are specification bugs, ie. we implemented X but actually need Y. This can certainly introduce exploits in the sense of customer surprise that say, some private information is revealed when they didn't expect it, but I'm not sure I would call this a hack. The device is working perfectly as expected, it's the expectations themselves that were wrong.
Don't be naive... security is a deep and subtle problem, full of nasty surprises. There is no magic bullet solution... your "safe programming language" has thousands of bugs in its standard API and run-time
I think you should update your knowledge of this field. Then you should also realize that over 90% of security vulnerabilities in programs written in unsafe languages wouldn't have occurred with safe languages. And of the vulnerabilities among safe languages, 90% of those wouldn't have occurred if they were designed to be capability secure (which is just another safety property most languages ignore).
it won't prevent devs from concatenating SQL with user input
You can't do this in, say Haskell, unless you write your own SQL interface library that builds solely on strings.
misusing threading primitives
You can't do this in concurrent safe languages, like Concurrent ML, Rust and Haskell.
bungling up an authentication protocol
Session types, which Haskell can verify too. Of course, all of these safety properties are encodable in even more powerful systems, like Agda or Coq.
you must at minimum use an approach where (1) security is a primary design concern thru the entire product lifecycle, (2) security solutions are deployed in a structured/layered approach using (3) actual expertise, and (4) security is an ongoing program with both proactive and reactive elements.
So basically, safety properties have importance on par with domain requirements, and must be subject to the same rigour that domain features get, ie. testing, verification, etc. So basically, the safer the language, in the sense that the more properties can be assured at compile-time, the more features and safety properties you can verify, and the fewer security vulnerabilities.
Last I checked, programming languages are designed and implemented by human beings. Even if a programming language can decrease your attack surface, there could still be an exploit associated with the interpreter/compiler or a mistake in implementation of the language.
That's what theorem provers are for. The seL4 microkernel was just formally verified as correct, we have verified C compilers, we have C verification tools (Frama-C for instance), and we have higher level, safer languages even at the systems level (Ada and Spark-Ada). This isn't an open theoretical CS question anymore, these technologies can and have been used very successfully to produce formally verified software, but the inertia behind outdated technologies and the hubris of developers who think they know better will continue to result in exploitable software.
The idea that there's a non-zero probability that your compiler, the theorem prover used to certify it, and the theorem prover used to certify that theorem prover, may all have a bug that coincidentally permit an exploit is about as meaningful as the argument that hypothetically, QM implies there's a non-zero probability that you could spontaneously be transported to the surface of the sun.
Costs are a big issue, but the problem with fusion is getting more energy than is put in... and keeping that reaction sustained indefinitely.
I think the real problem is how much we've fixated on only one or two fusion reactor designs for decades. Plasmas are hard to control, hence why it's taking so long to materialize real fusion power. They've pursued the Tokamak too long I think, but they keep going after it because they're already so heavily invested. Time for some fresh thinking.
Slashdot Mirror
That's an excellent and underappreciated point. The only difference between a morally reprehensible government-sanctioned action against a terrorist, and an action against you is an easily manufactured excuse. If morally reprehensible actions were never permitted, then the citizens need never fear their own government, which was the whole point of the constitution to begin with.
Except that doesn't work, because people being tortured will say anything to make it stop. At no point when they change their stories can you be certain they're now telling the truth. Even if their stories suddenly match, it could be a complete fluke, or as a result of the interrogator asking leading questions. Torture is useless.
It's not curious at all. The goal was to determine if a computer can decide with certainty whether another agent intends to do harm. This is obviously unsolvable, even for humans. Of course, we don't require humans to be absolutely certain in all cases before pulling the trigger, we just expect reasonable belief that oneself or others are in danger (for a self-defence argument). Reasonable belief is even easier to decide for computers, since the internal states resulting in that conclusion are fully available to us (unlike the human mind).
You seem to be speaking for "the community", but I don't see any hard numbers suggesting that the majority of said community actually shares your opinions. Just because many voices cry out and cry loudly, does not make those voices representative of anything meaningful.
You don't understand how garbage collection works.
Sure, but triggering side-effects during a fold can be perfectly sensible, and this doesn't make functional programming languages any less functional. Find me one person that considers this program to be non-functional, as your definition does:
let main = let list = [10; 2; 99; 30; 3] in
map (fun x -> printf "%d\r\n" x);;
Oh, I also forgot to mention:
Except this can lead to extremely high latency due to cascading deletions, which is another potential source of performance problems in C/C++. If you try to bound the amount of work to do to avoid this problem, you necessarily introduce reclamation latency. Reclamation latency isn't necessarily a bad thing.
Because smart pointers are degenerate garbage collection.
Scheme, Lisp, OCaml are all functional languages that are not referentially transparent. Pure functional languages require referential transparency, but impure functional languages do exist.
JavaScript is a functional language, but it's also procedural and object-oriented.
Sure they do, you're less likely to go through the hassle of creating a data structure that would be optimal for your domain simply because of the complicated memory management issues it raises. This is a complete non-issue with GC'd languages, so you're far more likely to do the (asymptotically) right thing.
More people does not necessarily mean more risk. More people can in fact, and often does, mean less risk.
Income redistribution plans apply to everyone. Obamacare applies only to those who get health insurance. Therefore, it's not an income redistribution plan.
Obamacare is an income redistribution plan the way having a job is a coffee cup redistribution plan. Just because A can cause B, does not entail that A is a B in the sense you are implying.
Partly, but they also don't want the Democrats to get the credit for something that could be very successful.
Since you argue about systemd from a user's perspective, then your own argument implies that you shouldn't care at all what sort of init system is in place, so why be against systemd? Given your view, it's purely a distribution's choice what init system to use because it's largely invisible to the user.
I doubt that very much. Most likely many of the ridiculous laws on the books are not enforced (like laws on sexual position), but that's not the same as what's illegal being roughly synonymous with what's wrong. It's a much repeated claim that pretty much everyone breaks some law at least once per day in the US.
I don't know what you're talking about. If anything, that would be "90% fewer security vulnerabilities", which sounds like perfectly good marketing.
I never said Haskell was the perfect language, just that it provides good examples of achieving the needed safety properties, in that it can be extended to verify many properties that may be of interest. I didn't define "safe" in my original post, as the requried "safety" properties are domain-specific. Memory safety is the minimum needed, which would automatically handle one of the most common vulnerabilities in single programs (buffer overflows). A language that can be used to specify and check the required properties is a "safe" language for a given domain. Many languages fit most problems, few languages may be safe for all problems (although possibly undesirable for other reasons).
If all we had were Haskell's DoS vulnerabilities, we would be in a much better place.
Not a chance. Here's a list of the top 25 exploits from 2011. From this list, numbers 3 and 20 would have been solved right away by using any memory safe language. Most memory safe languages also implement overflow checking, so that's 24 off too.
Languages featuring parametric polymorphism can tag unsafe values received as user inputs, so you can easily solve vulnerabilities 1, 2, 10, 14, 22, and 23 (all you really need is parametric polymorphism -- I've even done this in C#).
The crypto entries can be handled with session types that expect encrypted packets, not plaintext. Even the selection of appropriate crypto algorithm can be constrained by various parameters and checked at compile-time, ie. a Haskell type class constraint could specify a whitelist of unbroken crypto algorithms for unrestricted use, and those which are only good in restricted scenarios.
Design by contract can handle precondition violations, ie. #18, and such contracts can be statically checked these days in Haskell, C# and Ada.
A capability-secure language would handle the rest (mainly "porous defense" category remains). Few languages implement full capability security properties, and they remain vulnerable to the extent that they violate those principles.
The point is that the needed safety properties to address most common security vulnerabilities have been known for decades. Capability security was invented in the 1960s, and memory safety has been available since the first Lisp. Unfortunately, many programmers aren't interested in safety properties because they're focused too much on raw speed, but don't want to spend the verification effort to use that speed safely (Frama-C or Ada), or they want to avoid all verification effort period (dynamically typed languages).
No, that's not how it works. You don't outlaw all possible bad behaviours, you enable only the behaviours you want to achieve the features you need. Everything is is forbidden statically.
With a theorem prover like Coq, you can statically check any property you want. So you'll have to more precisely define "unhackable" before "it is impossible to create something that is completely unhackable" can have a truth value.
If used extensively, the only bugs you can introduce with a theorem prover are specification bugs, ie. we implemented X but actually need Y. This can certainly introduce exploits in the sense of customer surprise that say, some private information is revealed when they didn't expect it, but I'm not sure I would call this a hack. The device is working perfectly as expected, it's the expectations themselves that were wrong.
I think you should update your knowledge of this field. Then you should also realize that over 90% of security vulnerabilities in programs written in unsafe languages wouldn't have occurred with safe languages. And of the vulnerabilities among safe languages, 90% of those wouldn't have occurred if they were designed to be capability secure (which is just another safety property most languages ignore).
You can't do this in, say Haskell, unless you write your own SQL interface library that builds solely on strings.
You can't do this in concurrent safe languages, like Concurrent ML, Rust and Haskell.
Session types, which Haskell can verify too. Of course, all of these safety properties are encodable in even more powerful systems, like Agda or Coq.
So basically, safety properties have importance on par with domain requirements, and must be subject to the same rigour that domain features get, ie. testing, verification, etc. So basically, the safer the language, in the sense that the more properties can be assured at compile-time, the more features and safety properties you can verify, and the fewer security vulnerabilities.
I'm sure it would seem funny to someone who doesn't understand what "safe" means, in a technical sense.
That's what theorem provers are for. The seL4 microkernel was just formally verified as correct, we have verified C compilers, we have C verification tools (Frama-C for instance), and we have higher level, safer languages even at the systems level (Ada and Spark-Ada). This isn't an open theoretical CS question anymore, these technologies can and have been used very successfully to produce formally verified software, but the inertia behind outdated technologies and the hubris of developers who think they know better will continue to result in exploitable software.
The idea that there's a non-zero probability that your compiler, the theorem prover used to certify it, and the theorem prover used to certify that theorem prover, may all have a bug that coincidentally permit an exploit is about as meaningful as the argument that hypothetically, QM implies there's a non-zero probability that you could spontaneously be transported to the surface of the sun.
Not if you take appropriate precautions, like using a safe programming language.
I think the real problem is how much we've fixated on only one or two fusion reactor designs for decades. Plasmas are hard to control, hence why it's taking so long to materialize real fusion power. They've pursued the Tokamak too long I think, but they keep going after it because they're already so heavily invested. Time for some fresh thinking.
So I can surmise that you program in Ada?
The existence of stressors is not necessarily bad. How you deal with stress is more important.