Yeah, that part sucks. And itâs a huge loss for GNU as a project.
But I donât feel like GNU has been a good steward of such vital infrastructure, it shows many signs of a broken project. Software will have critical bug fixes committed to their repository but then fail to cut a release for a long time. GNU M4 was once incompatible with GNU glibc for years because glibc changed something which caused M4 to stop compiling, M4 got a fix committed to its repo, but no new release of M4 was made.
GNU as an operating system is stuck in the 80s; the only reason GNU has seen any success in the past 30 years is that others have picked up the slack for core operating system components like kernels, init systems, graphical environments, etc.
The GNU âoperating systemâ delivers an excellent compiler collection, an okay libc with significant issues such as incompatibility with static linking and intentional lack of âforward compatibilityâ, an atrociously terrible build system, and an alright but stagnant set of commands line utilities and shell. Itâs not a project that I feel deserves a lot of fealty. Although I do think itâs a tragedy that the project turned out this way, I think weâre well past the time where it makes sense to look at it critically and pick up the pieces with value (such as the compiler collection) and abandon the pieces without (such as the build system, arguably the coreutils, maybe eventually the libc; a man can dream).
This is a big change, and shows an impressive level of courage. I love to see how the leadership in Ubuntu can unafraid to be bold and question traditional ways of doing things (even though that sometimes results in results I find disagreeable, e.g snap packages).
I have recently had to run a vulnerability scanner against an embedded Linux system, and was surprised to find CVEs relating to memory safety bugs in recent versions of old GNU tools youâd think would have those sorts of issues ironed out by now, like GNU patch (and various Busybox tools for that matter). From an âexploitable memory safety bugâ perspective, I think I would trust even a relatively young project like uutils over even old, battle-tested C software.
Slowly but surely replacing copyleft software đ
(with MIT here)
Yeah, that part sucks. And itâs a huge loss for GNU as a project.
But I donât feel like GNU has been a good steward of such vital infrastructure, it shows many signs of a broken project. Software will have critical bug fixes committed to their repository but then fail to cut a release for a long time. GNU M4 was once incompatible with GNU glibc for years because glibc changed something which caused M4 to stop compiling, M4 got a fix committed to its repo, but no new release of M4 was made.
GNU as an operating system is stuck in the 80s; the only reason GNU has seen any success in the past 30 years is that others have picked up the slack for core operating system components like kernels, init systems, graphical environments, etc.
The GNU âoperating systemâ delivers an excellent compiler collection, an okay libc with significant issues such as incompatibility with static linking and intentional lack of âforward compatibilityâ, an atrociously terrible build system, and an alright but stagnant set of commands line utilities and shell. Itâs not a project that I feel deserves a lot of fealty. Although I do think itâs a tragedy that the project turned out this way, I think weâre well past the time where it makes sense to look at it critically and pick up the pieces with value (such as the compiler collection) and abandon the pieces without (such as the build system, arguably the coreutils, maybe eventually the libc; a man can dream).
Wow, it would be a huge endorsement of uutils if a big distro like Ubuntu switched to it.
I need to get around to filing bug reports for the minor problems Iâve had.
This is a big change, and shows an impressive level of courage. I love to see how the leadership in Ubuntu can unafraid to be bold and question traditional ways of doing things (even though that sometimes results in results I find disagreeable, e.g snap packages).
I have recently had to run a vulnerability scanner against an embedded Linux system, and was surprised to find CVEs relating to memory safety bugs in recent versions of old GNU tools youâd think would have those sorts of issues ironed out by now, like GNU patch (and various Busybox tools for that matter). From an âexploitable memory safety bugâ perspective, I think I would trust even a relatively young project like uutils over even old, battle-tested C software.