Carefully But Purposefully Oxidising Ubuntu

58 points by steveklabnik

ThinkChaos

Slowly but surely replacing copyleft software 🙁
(with MIT here)

mort

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).
- ThinkChaos
  
  Sounds like we agree, I appreciate the examples :)
  I’m pro replacing or improving software, especially of core utility to a system. I’m also pro having such core code copyleft.
- fs111
  
  What is the reason that the GNU project is as dysfunctional as you describe (for certain projects)? Lack of fresh talent? Broken leadership? Politics?
  
  I am curious because I have no insights into GNU but I never perceived the tools as so poorly maintained
  - paddy
    
    Broken leadership. Stallman is correct about freedom but wrong about product management. He ends up being a huge distraction (comments about minsky in particular).
    
    There have been multiple examples of him not allowing features to be merged because they could enable closed competition, where the GNU alternative doesn’t exist or isn’t as good. In multiple cases he has had to relent after months or years because a different competitor implemented the same feature and its become obvious how far behind he is.
    
    Making it cumbersome to add extensions to GCC because that could allow non-free stuff to be built on top of it. Clang and LLVM made this trivial from the start. Eventually GCC allowed easier extensions.
    
    Allowing Emacs to better integrate with LLVM, debugger-adapter-protocol,tree-sitter, LLVM. He stalled all of these projects and they were all eventually merged.
    
    insisting that Emacs use BZR and his own weird inhouse github clone. Emacs is on git after years of messing with bzr, while most devs used a bzr-git bridge.
    
    Stalling any integration with modern CI for Emacs.
    
    In a lot of cases he is fighting against GPL licensed alternatives (bzr/git), that aren’t under the GNU umbrella. Sometimes he’s fighting against more permissively licensed software.
    
    If free software isn’t made better, it will lack adoption.
  - mort
    
    Honestly I have no idea. I’m also just an outside observer.
- lonjil
  
  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.
  - janus
    
    would it be the biggest differentiator from Debian since Upstart or is there something else?
    
    kwas
    
    Comment removed by author
  - mort
    
    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.
  - viraptor
    
    So even though the post mentions “alternatives” a few times, it never says why a new system is proposed instead of the existing update-alternatives (https://manpages.ubuntu.com/manpages/trusty/man8/update-alternatives.8.html) It seems like it should’ve been he first choice here?
    
    steveklabnik
    
    It’s described in the discourse thread: alternatives requires cooperation with the other package. If this gets closer to becoming a reality, then they’ll do this integration, but they want to kick the tires for a bit before doing that.