Announcement

Collapse
No announcement yet.

Linux Foundation Announces A Core Infrastructure Initiative

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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.

    Comment


    • #12
      What about GnuTLS???

      Comment


      • #13
        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/

        Comment


        • #14
          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, 06:41 PM.

          Comment


          • #15
            Originally posted by cutterjohn
            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.

            Comment


            • #16
              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.).

              Comment


              • #17
                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.

                Comment


                • #18
                  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.

                  Comment

                  Working...
                  X