Small learning curve? Good examples? Cost? etc..
views:
31answers:
4Yeah...but that's a bit vague. What makes it "useful"? Are incredibly verbose and convoluted frameworks "useful" if all the features are there, but they're just ridiculous to use? Or does that impede usefulness? Is convention-over-configuration useful, or is that a feature you don't care for?
Mark
2010-08-01 22:58:05
@Mark: Evaluate on a case-by-case basis. Why would I care about a framework that isn't useful? Note that his question is the problem: it's totally ridiculous and should be closed. Answers here are more "what makes a good framework" and the answer is obviously "good practicies". His question asks for the first thing to consider. I delivered on that question.
Noon Silk
2010-08-01 23:01:18
@Mark The question was simply asking what entices you to start playing with a library / framework. Not what makes you stick with it. The only thing that entices me to play with a library or framework is usefulness. Whether I continue with it is another matter that is generally decided after a few hours or a day of playing with it and reading the documentation.
Simon
2010-08-01 23:02:27
@Simon: I didn't say anything about "sticking with it". I simply asked how he defines usefulness. If you define useful as whether or not you find the features helpful *after* having played around with it..then you've missed the boat. As you quoted, "entices you to start..."
Mark
2010-08-01 23:09:31
+2
A:
- Good solid design
- Open source
- Not coded in an insecure language such as C/C++/PHP
- Not coded in a bad language like Perl/COBOL/VB/PHP
- Something that's relevant to my interests?
Longpoke
2010-08-01 22:48:26
Security is less to do with the language and more to do with the programmer. It is perfectly possible for a programmer to turn a so called 'secure' language and turn it into a security nightmare. On the other hand it is also perfectly possible to write robust code in C for example.
Simon
2010-08-01 22:50:40
No it isn't. Linux already proved this and does every month. The only provably secure code in C I know is 2K lines of C, and 200K lines of proof.
Longpoke
2010-08-01 22:52:27
"It is perfectly possible for a programmer to turn a so called 'secure' language and turn it into a security nightmare." My good solid design point removes the possibility of this.
Longpoke
2010-08-01 22:53:16
I'm amazed that at least two people agree to discarding a library based on the 'insecure language' theme. I'd certainly like to see how they code in their 'secure' languages.
Vinko Vrsalovic
2010-08-01 22:57:28
Good solid design does not account for algorithms being incorrect or other security problems which have nothing to do with the language itself. The fact of the matter is that if you assume a piece of code is more secure simply because of the language it is written in you are asking for trouble.
Simon
2010-08-01 22:58:30
@Simon: 1. Weather a crypto algorithm is broken or not is a math problem. Other non-security sensitive algorithms are kind of irrelevant... 2. A lot of libraries simply aren't security sensitive... such as a graphing library, why would I want that written in C? If it's in C, it can be smashed and take over my app, and steal all my info that the app doesn't even use. If it's in Java, I can isolate it and it can't do anything other than return values to the rest of my code...
Longpoke
2010-08-01 23:06:39
@Silky, elaborate. I choose my libraries over this criteria, dunno what you're trying to imply.
Longpoke
2010-08-01 23:08:36
@Longpoke: Crypto-algorithms can be broken by poor implementation or side-channel attacks. This is actually the most common way. Non-security "sensitive" "algorithms" are important in how they handle data input, see previous comment, see previous comment, Java has no real special abilities. It has a sandbox, but it's occasionally found to have flaws, and the sandbox can be running at high enough priviledges to do something dangerous.
Noon Silk
2010-08-01 23:10:55
@silky: That's why you use a good library for crypto... No, Java has a real domain isolation architecture, I'm pretty sure .NET has something similar as well. And even the Java sandbox alone is good enough to stop broken code from stealing your ~ (except for when it has vulns, but these are **rare** compared to *nix kernel vulns for example).
Longpoke
2010-08-01 23:13:22
@Longpoke: There is no point continuing this discussion. I've elaborated; you are wrong, and that is that. I'll leave it to others.
Noon Silk
2010-08-01 23:13:58
@sikly: Wrong about what? My answer contains no arguable predicates other than claiming C is insecure, which it is, and bad languages, which are mine and most others' opinions. You are just arguing against random points I made for no apparent reason. This is my opinion, this is how I pick libraries, I can properly contain anything that isn't compiled to assembly language, small trusted code base, nanokernels, and domain isolation is where modern OS are heading, I am just helping that by writing all my code in portable, secure languages, to ease the porting process.
Longpoke
2010-08-01 23:17:20
@Longpoke Pretty irrelevant, especially when you look at the bugs in Java and C# which quite often allow arbitrary code execution. Plus the fact that it is incredibly easy to write insecure code in either language anyway (as it is with any language). All you need to do is forget to sanitise user input and BOOM you have a security flaw in your supposedly 'secure' Java web application.
Simon
2010-08-01 23:20:29
@Simon, The main point is pretty much that you can use any library that runs on JVM without having to care if it has security problems, because it's isolated from everything else. You can't do this with anything written in C without either syscall traps (SELinux) or an emulation layer which both introduce another layer of attack surface. Then again you can run the code on another account, which isn't really an ideal solution at all because now you need IPC and privilege lowering and all that.
Longpoke
2010-08-01 23:29:30
In all these 3 alternate mitigations, the broken code still has direct access to syscalls which is enough to escalate because the Windows/*nix kernels are both vulnerable. Meanwhile, the isolated JVM code can only run JVM code which can't access the user's private information, and isn't likely to be enough to directly break the kernel, they have to break out of the sandbox first... And no, the sandbox isn't nearly as vulnerable as kernels are...
Longpoke
2010-08-01 23:31:46
A:
These three for me:
1) Has the functionality I need
2) Has a good website where it is easy to find documentation and download
3) Has an easy to find, step-by-step tutorial showing the most frequently used Use-Cases and the power of the framework
An example of a good framework: http://www.sfml-dev.org/
An example of a bad framework - if it weren't so famous, I would never give it a try (which would be a shame): http://www.springsource.org/
First impression matters!
dark_charlie
2010-08-01 22:53:33
A:
- A following -- If people go gaga over it, it's usually for a reason (even if that reason is crap)
- A new and exciting feature that no other framework has
- Good DRY and Convention-Over-Configuration
- Clean and concise
- It uses a language I like (but not necessarily know)
- Their website is pretty and the documentation doesn't suck -- Seriously, if the site doesn't look polished, then I assume the framework isn't either
Mark
2010-08-01 22:53:37