This is the kind of divorced from reality slop I expect to see from managers who think that 9 mothers can birth a child in one month

I don't understand comments like this

It’s a wishlist of Open tickets. Wouldn’t necessarily even call this a commitment to a roadmap.

Roadmaps are just wishlists with a committed to priority list, like an assembly line. Programming doesn't work like an assembly line and anyone trying to convince you to the contrary is ~~bullshiting~~ marketing.

Every task has the potential to bring forwards new information that changes the order in which tasks should be completed, let alone which tasks even need to attempted. You only get all the information once you've finished.

Instead of having an inflexible commitment, use a wishlist, and do the tasks in order of which one makes the most sense at the time.

75% of Open tickets will never get resolved anyway.

Based on what?

You can clearly see that practically all tickets in their previous epoch were resolved: https://github.com/orgs/pop-os/projects/23/insights?period=max

If I were a uutils developer, I would stay far away from all of these discussions because of how much hate is directed towards it.

I only see the hate towards this project being either from anti-rust trolls, or misdirected hate from Ubuntu towards switching to a new coreutils implementation on an LTS release before full compatibility has been achieved. I don't see any hate in regards to licensing.

If they do not adopt the license you prefer, would it be better for them to just go ahead and abandon the whole effort? Are there efforts really so valueless simply because they chose the license that they did?

Their efforts have value, but the value is limited by it's current licence. MIT licenced projects have a recurring history of being improved privately without those improvements going back into the project. It leads to a lot of duplicated, wasted effort. There may also be the potential for patent issues with the licence. No one wants to deal with some litigious asshole or company going after the project turning it radioactive.

Moreover, is dictating to volunteers what license they should be using for their code what you think this community should be about?

I think bringing up issues with the project is definitely something that should be brought up. As for dictating which particular licence is used, that's up to the contributors, but that doesn't mean others can't give their input. It's also likely that most of the contributors will want a license that allows the project to safely continue into the future.

You claim that it is important that people make tons noise in every single post on uutils because it will prevent a bad scenario down the line, but could you detail what that scenario is? Because people like to make allusions to such a scenario constantly but refuse to get specific and then engage on a discussion on the specifics.

I thought the Redis example was a good example of this.

Incidentally, your choice of Redis is an example exactly illustrates my point that this license is not a gigantic deal it shows that the worst case scenario is… uutils being forked.

The community was fractured. A report by an enterprise support company said 75% of existing redis users were motivated to seek alternatives. I'm not sure what number you would consider to be a gigantic deal, but Redis certainly thought it was, otherwise they would not have reverted back to the previous license.

Heck, it can even be forked at any time with a copyleft license precisely because its existing language is permissive.

It can be forked, but relicensing can mean needing permission from every contributor of the original, and/or removing all contributions from those who don't agree to the new licence. Not to mention the community fracturing, and legal issues. It's a massive effort that can be prevented by the original project choosing a better license earlier.

You claim that it is important that people make tons noise in every single post on uutils because it will prevent a bad scenario down the line, but could you detail what that scenario is? Because people like to make allusions to such a scenario constantly but refuse to get specific and then engage on a discussion on the specifics.

Well this comment is probably getting too long, so I'll simply point you towards the busybox licensing drama.

So it needs to be commented on in every single article?

Yes

If so, is that going to change anything?

Potentially.

The alternative is not bringing up the concern and it goes forgotten until it is too late and we are stuck with the results of bad decisions for no good reason.

Developers voicing their concerns is the only way things can change for the better.

Here's two examples:

1. Redis licensing rug pull

   • Redis unexpectly changed its own licencing
   • Developers demanded Redis return to its original (or similar) licence
   • Redis said no
   • Developers formed their own Redis clones from scratch with compatible APIs
   • Developers switched to the new Redis replacements
   • Redis returned back to the original licence in an attempt to keep existing users

2. Google's JpegXL whiplash

   • Google added support for jpegxl in Chrome
   • Google removed support for jpegxl in Chrome in favour of inferior standards
   • Developers demanded support added back
   • Google said no
   • Developers flooded every issue tracker and feature request with support for jpegxl, consistently, unrelentingly, for years
   • Other browsers add support for jpegxl
   • Creative industry adds support for jpegxl
   • PDF association adds support for jpegxl
   • Google forced choose between jpegxl or fall out of supporting pdf standard
   • Google readds jpegxl support

And there's plenty of other examples (e.g. Microsoft against linux -> WSL support, etc...)

If developers don't voice their concerns, then things stop changing for the better.

Licencing is a legitimate concern (not noise), even more so considering it's for the core utils

macOS has far better desktop applications across the board than Linux. What you get for free with a Mac is nothing to sneeze at:

Counterpoint: The apple of yore is not the apple of today.

Recent examples:

• https://noheger.at/blog/2026/01/11/the-struggle-of-resizing-windows-on-macos-tahoe/
• https://blog.johnozbay.com/what-happened-to-apples-attention-to-detail.html
• https://tonsky.me/blog/tahoe-icons/
• etc...

At this point, the beginner-friendly linux distros (Linux Mint, Ubuntu, Kubuntu, Bazzite) are more sensible and logically consistent than either Windows or MacOS.

Tangent: If you're looking at paid git clients on MacOS, I'd recommend fork over Git Tower or Kaleidoscope.

Significant whitespace, minimal ceremony

Well that's an oxymoron. If you're having to alter the whitespace instead of the code because the whitespace is significant than all you have is ceremony.

Not if the standards rely on dedicated hardware, for example: security enclaves.

The whole point of using a security enclave on different hardware is so that its memory cannot be accessed or polluted by a process or side channel attack on the main hardware.

What's with all the complaints here?

New users expect middle click to bring up an auto-scroll widget instead of pasting by default.

You can set up your computer how ever you want.

Want auto-scroll? Set it to auto-scroll.

Want paste? Set it to paste.

The first thing you do on a new system is set up the computer how you want.

No one's taking anything away from you.

I don't see any actual temper lost here.

In one case he points out that someone is making commits that have messed up a file's indentation, and to stop doing that because it's messing things up (they were).

In the other case he points out that rust's default format rules are wrong (in the context of version control readability, they are) and asks someone to fix them.

That's 41 degrees for everyone who doesn't measure things in bird per gun.

Github has always had being a job site be it's secondary feature.

Except that it has a slightly higher bar of entry to recruiters and recruitment bots spreading toxic positivity, and anyone asking for a job is able to prove (at least some of) their value by showing off their code and how they participate publically in other repos (if at all).