GNU C Library 2.34 Released With More Functionality Squeezed Into libc

[phoronix]

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?page=news_item&px=GNU-C-Library-Glibc-2.34

[uid313]

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.

[jrch2k8]

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.

[archkde]

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?

[rene]

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

[evasb]

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.

[bountykiller]

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)

[discordian]

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.

[linuxgeex]

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.

[coder]

glibc implements POSIX which is not as good as Windows.

You are misinformed.

Pipes on POSIX are unidirectional, it is not bidirectional.

It's just a matter of whether to use one or two.

Windows named pipes are much better

Better in what ways?

support full-duplex bidirectional communication,

Already covered that.

peeking reads without consuming the buffer,

Usually not a big deal.

as well as both blocking and non-blocking read and writes.

So does Linux.

POSIX can not lock files,

Linux has mandatory locking, but it's usually avoided because it causes more trouble than it's worth.

https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt

applications have workaround this by creating their own lock files to hint to themselves that it is locked.

That's not true. You can do advisory locking on the files, themselves.

On Windows you can pass an argument when you open the file that lets to exclusively open the file.

And the rampant overuse of this "feature" is one thing I hate about Windows.

On Windows you have async I/O.

Same on Linux.

Quit trolling, dude. Seriously.