Announcement

Collapse
No announcement yet.

GNU C Library 2.34 Released With More Functionality Squeezed Into libc

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

  • GNU C Library 2.34 Released With More Functionality Squeezed Into libc

    Phoronix: GNU C Library 2.34 Released With More Functionality Squeezed Into libc

    Version 2.34 of the GNU C Library (glibc) is now available with a wide variety of changes that accumulated over the past six months...

    https://www.phoronix.com/scan.php?pa...ary-Glibc-2.34

  • #2
    glibc implements POSIX which is not as good as Windows.

    Pipes on POSIX are unidirectional, it is not bidirectional. Windows named pipes are much better and support full-duplex bidirectional communication, peeking reads without consuming the buffer, as well as both blocking and non-blocking read and writes.

    POSIX can not lock files, applications have workaround this by creating their own lock files to hint to themselves that it is locked. On Windows you can pass an argument when you open the file that lets to exclusively open the file.

    On Windows you have async I/O.

    Comment


    • #3
      Originally posted by uid313 View Post
      glibc implements POSIX which is not as good as Windows.

      Pipes on POSIX are unidirectional, it is not bidirectional. Windows named pipes are much better and support full-duplex bidirectional communication, peeking reads without consuming the buffer, as well as both blocking and non-blocking read and writes.

      POSIX can not lock files, applications have workaround this by creating their own lock files to hint to themselves that it is locked. On Windows you can pass an argument when you open the file that lets to exclusively open the file.

      On Windows you have async I/O.
      after using both i take POSIX any day of the week even tho you are right there are downsides but on the other hand Windows API is horribly convoluted and unstable, that may have changed since i have years without touching WIN32 API but back in the days BSOD and hacks was the rule of the day.

      Comment


      • #4
        Originally posted by uid313 View Post
        glibc implements POSIX which is not as good as Windows.

        Pipes on POSIX are unidirectional, it is not bidirectional. Windows named pipes are much better and support full-duplex bidirectional communication, peeking reads without consuming the buffer, as well as both blocking and non-blocking read and writes.
        Isn't that basically what a socketpair does?

        Comment


        • #5
          and in good GNU tradition, a couple of annoying regressions :-/ https://www.youtube.com/watch?v=YgIgALjpXeU&pp=sAQA

          Comment


          • #6
            Moving forward, Glibc has gone ahead and dropped its FSF copyright assignment policy.
            I'm pretty much in favor of this move for practical reasons, but it's pretty sad that these decisions are driven by ressentiment against FSF decision of reinstating RMS in the council board. RMS, ESR were cancelled and even Linus was in risk of being cancelled some time ago and was forced to accept a Contributor Covenant.

            GNU is pretty much dying a show death and its components are being replaced by permissive rewrites, many are dependent on FSF funding, I hope this isn't a shot in the foot.

            Comment


            • #7
              Originally posted by uid313 View Post
              Pipes on POSIX are unidirectional, it is not bidirectional. Windows named pipes are much better and support full-duplex bidirectional communication, peeking reads without consuming the buffer, as well as both blocking and non-blocking read and writes.
              You can use socket for that for example.

              POSIX can not lock files, applications have workaround this by creating their own lock files to hint to themselves that it is locked. On Windows you can pass an argument when you open the file that lets to exclusively open the file.
              False, in posix, you can lock files directly using lockf.

              On Windows you have async I/O.
              Even if I never used it,it seems that you can do it using the aio_ familly of functions (for my part I generally use libevent or boost::asio for this)

              Comment


              • #8
                Originally posted by uid313 View Post
                glibc implements POSIX which is not as good as Windows.

                Pipes on POSIX are unidirectional, it is not bidirectional. Windows named pipes are much better and support full-duplex bidirectional communication, peeking reads without consuming the buffer, as well as both blocking and non-blocking read and writes.

                POSIX can not lock files, applications have workaround this by creating their own lock files to hint to themselves that it is locked. On Windows you can pass an argument when you open the file that lets to exclusively open the file.

                On Windows you have async I/O.
                just use AF_UNIX sockets, way better than windows pipes and can be used transparently with inet sockets.

                There are mandatory and optional locks in Linux (not sure how much of it is specified in POSIX). And constantly having locked files is a big pain on windows.

                There are various async IO libraries, both in userspace (even glib has one) and with kernel support (io_uring).
                When it comes to IO speed Linux handily beats windows at any rate.

                So I doubt you really did substancial POSIX programming (which is supported pretty much everywhere down to realtime and microcontrollers OSes).

                The things that are a mess in Linux/POSIX are pid and signal handling, and fork/exec madness (can get really ugly with open fd). Windows mostly gets away by not supporting fork and not sharing executable memory between processes, wasting tons of memory and having really slow process startup times.
                ​​



                Comment


                • #9
                  Originally posted by evasb View Post

                  I'm pretty much in favor of this move for practical reasons, but it's pretty sad that these decisions are driven by ressentiment against FSF decision of reinstating RMS in the council board. RMS, ESR were cancelled and even Linus was in risk of being cancelled some time ago and was forced to accept a Contributor Covenant.

                  GNU is pretty much dying a show death and its components are being replaced by permissive rewrites, many are dependent on FSF funding, I hope this isn't a shot in the foot.
                  The real reason for the dropping the FSF copyright assignment is that it allows professionals to write code and license it for use with GPL without surrendering their rights to use their work in their own professional setting which may include GPL-incompatible settings.

                  FSF demanding copyright assignment was an example of them being co-opted into a radicalised socialist cult by RMS' mental illness. RMS basically states: "nobody should have to reinvent the wheel, ever, and my POV trumps any and all real-world scenarios, and if you disagree you are a freedom heathen."

                  I agree that nobody should have to reinvent the wheel. But browbeating/bullying contributors because they don't fit your sociological viewpoints, as a means to a better word? Not so much.

                  While RMS was away, FSF was freed from that bullying and was enabled to make some sensible community decisions, and I can only hope that they continue to do so, keeping RMS' opinions solely as a cautionary tale, instead of treating them like law. His paranoia remains valuable as a canary in a coal mine... but not for a leadership role.
                  Last edited by linuxgeex; 02 August 2021, 05:57 PM.

                  Comment


                  • #10
                    Originally posted by uid313 View Post
                    glibc implements POSIX which is not as good as Windows.

                    Pipes on POSIX are unidirectional, it is not bidirectional. Windows named pipes are much better and support full-duplex bidirectional communication, peeking reads without consuming the buffer, as well as both blocking and non-blocking read and writes.

                    POSIX can not lock files, applications have workaround this by creating their own lock files to hint to themselves that it is locked. On Windows you can pass an argument when you open the file that lets to exclusively open the file.

                    On Windows you have async I/O.
                    Well, posix was meant to be a compatibility standard between operating systems. Windows implements posix too. But there are more features outside the realm of posix (and SUS) in Linux, and there are more libraries than libc to use... I will not go into what you can and cannot do on Linux vs. Windows (which is constantly evolving) but I just wanted to note that targeting posix as a programmer would have been a pragmatic decision allowing (in theory) your code to function on any of the posix compliant operating systems. Targeting the Windows api (or using Linux-specific stuff) only guarantees it will run on those platforms. (This is somewhat blurred today because of the existence of virtualisation and compat layers like Wine and WSL)

                    Comment

                    Working...
                    X