Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: Linux Foundation Announces A Core Infrastructure Initiative

  1. #11
    Join Date
    Dec 2012
    Posts
    97

    Default

    Re: OpenSSL/LibreSSL discussion.

    Right now I think there's plenty of room for both OpenSSL and LibreSSL. Eventually we might end up with a merger of some kind, or they might differentiate enough to just have the multiple options, who knows? Look at the good that's come from having something (LLVM/Clang) competing with GCC finally.

  2. #12
    Join Date
    Dec 2013
    Posts
    3

    Default

    What about GnuTLS???

  3. #13
    Join Date
    Apr 2010
    Posts
    7

    Default Funding people who failed, to fail with more vigor?

    Am I the only one, who thinks that funding a structurally failed enterprise is only going to yield more fail, more efficiently?

    To be entirely honest, this whole idea is thoroughly sickening from my point of view.

    The only way to fix OpenSSL is to throw it away, period.

    More practically, though, a temporary ABI shim is needed -- and LibreSSL fits the bill perfectly.

    In the long run, an API not designed by idiots is needed -- such as NaCl by Dan Bernstein:

    http://nacl.cr.yp.to/

  4. #14
    Join Date
    Jul 2013
    Posts
    199

    Default

    Quote Originally Posted by wargames View Post
    Yes, please, give some money to the Xfce devs so they can work full time on it. And let's not forget Gimp, Inkscape, Blender, LibreOffice, Openshot, Wine and others.

    Better development tools would be nice too. Something like Eclipse (a multi-purpose IDE) but without the bloat.
    If you want to see projects like Blender, GIMP, Krita, Inkscape and LibreOffice improved you could consider supporting the blender feature film project http://gooseberry.blender.org/ which aims to hire developers to improve these projects thoughout the process of making the movie.
    Last edited by tarceri; 04-24-2014 at 06:41 PM.

  5. #15
    Join Date
    Apr 2013
    Posts
    13

    Default

    Quote Originally Posted by cutterjohn View Post
    no, libressl is theo's little pet project, while openssl is what is actually used...

    which is better, IMNHO openssl, as I'm tired of theo's whinging about everything and anything, he's about as bad as zealot freetards with about as much relevance.
    I agree. The OpenSSL people have been working on it as a side project for ages and got jack for gratitude. Minuscule amount of donations and rarely a though as long as it worked. In a way this problem highlighted this and now they get the proper attention.

    The OpenBSD folks are just jumping the wagon of mixed publicity. It's good if they continue their fork as some competition is always good but it would be very a-holish to turn the back on the OpenSSL team who were working away with little gratitude for all this years.

    We should at least give them the benefit of the doubt and see what they can accomplish with proper funding and the ability to focus on writing OpenSSL instead of consulting all the time to keep afloat.

  6. #16

    Default

    Quote Originally Posted by _deepfire View Post
    Am I the only one, who thinks that funding a structurally failed enterprise is only going to yield more fail, more efficiently?

    To be entirely honest, this whole idea is thoroughly sickening from my point of view.

    The only way to fix OpenSSL is to throw it away, period.

    More practically, though, a temporary ABI shim is needed -- and LibreSSL fits the bill perfectly.

    In the long run, an API not designed by idiots is needed -- such as NaCl by Dan Bernstein:

    http://nacl.cr.yp.to/
    ...and also preferably something written in a language with support for stricter compile-time safety guarantees (eg. a post-1.0 release of Rust, ATS, SPARK, MISRA C, etc.).

  7. #17
    Join Date
    Apr 2010
    Posts
    7

    Default

    Quote Originally Posted by ssokolow View Post
    ...and also preferably something written in a language with support for stricter compile-time safety guarantees (eg. a post-1.0 release of Rust, ATS, SPARK, MISRA C, etc.).
    Absolutely.

    The only problem is the requirement of linkability by C users, but that's not insurmountable with modern FFIs -- albeit distinctly problematic.

  8. #18

    Default

    Quote Originally Posted by _deepfire View Post
    Absolutely.

    The only problem is the requirement of linkability by C users, but that's not insurmountable with modern FFIs -- albeit distinctly problematic.
    That's why I gave the list I did. I don't know about SPARK's FFI support, but MISRA C is a restricted subset of C, ATS is translated to C and then compiled, and Rust is designed to interoperate.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •