<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Feb 15, 2026 at 5:11 AM Jonathan Wakely <<a href="mailto:jwakely.gcc@gmail.com">jwakely.gcc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 15 Feb 2026, 08:36 Jeffrey Walton via cfarm-users, <<a href="mailto:cfarm-users@lists.tetaneutral.net" target="_blank">cfarm-users@lists.tetaneutral.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 15, 2026 at 2:57 AM Bruno Haible via cfarm-users <<a href="mailto:cfarm-users@lists.tetaneutral.net" rel="noreferrer" target="_blank">cfarm-users@lists.tetaneutral.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Paul Eggert wrote:<br>
> I tested for the compilation problem by compiling on <a href="http://cfarm111.cfarm.net" rel="noreferrer noreferrer" target="_blank">cfarm111.cfarm.net</a> with<br>
> /opt/IBM/xlc/16.1.0/bin/xlc. If you're using an older version of xlc, <br>
> that would explain why you see a compilation problem but I don't.<br>
<br>
Indeed, I was using the /usr/bin/xlc (which identifies itself as being from<br>
2012).<br>
<br>
> I suppose if IBM doesn't care enough to make that compiler <br>
> easily available then free-software maintainers shouldn't care enough to <br>
> port to it.<br>
<br>
Yes. And likewise for AIX: If IBM doesn't care enough to make an AIX box<br>
available to the Free Software community with reasonable usage terms,<br>
and if IBM doesn't care enough any more to employ the leading GCC developer<br>
for AIX, then why should GNU package maintainers continue to worry about<br>
portability to AIX?</blockquote><div><br></div><div>I think this is an echo chamber using flawed arguments. Effectively what is being argued is, if <X> does not support free software, then free software should not support <X>. I think that is a flawed argument.</div><div><br></div><div>Instead, I think the question to ask is, should free software support <X>, where X is a compiler like XLC or a platform like AIX. I think the answer to that question is Yes, because it <div style="display:contents">maximizes user freedom, maximizes interoperability, ensures broad access to GNU technology, and encourages collaboration</div>.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Maybe in an ideal world. But maintainers of free software should not be obliged to purchase proprietary software licenses to port their code to that platform, or go to extraordinary lengths to do so. </div></div></blockquote><div><br></div><div>I agree that maintainers should not be required to purchase software licenses, just like they are not required to purchase hardware. David Edelsohn procured two DGX Spark machines for the CFarm. Nvidia supplied them, as I understand things.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">The only obligation should be to accept patches for supporting such systems, and give them fair consideration. That means users/vendors of those systems can submit patches to the project, and the maintainers won't reject them out of hand because they don't want to support those systems. Expecting anything more from free software manufacturers is completely unreasonable IMHO.</div></div></blockquote><div><br></div><div>I agree that vendors and users should supply patches. However, in their absence, I feel maintainers should make an effort to port to other machines and operating systems, if only to improve the software for their core users. I can't count how many bugs I fixed when I ported to AIX (due to doing sketchy things that were not portable) or a big endian machine (because I made assumptions on amd64 that did not hold on POWERPCs).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>I also don't buy into the argument that the vendor no longer supports <X>, so we should not support <X>. I think that's another flawed argument. IBM and other companies like Microsoft and Google do not rule by fiat. The market determines what needs to be supported. </div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Then the market should provide patches. If users exist, they can install+test on their hardware and report bugs or provide patches. Expecting free software maintainers to do that without knowing if any users even exist is unreasonable. </div></div></blockquote><div><br></div><div>Ok, so here is where things start going sideways. First, I agree that vendors and users should supply patches. But second, some maintainers will start removing working code when a company like IBM or Microsoft declares their product obsolete. So the "patches welcome" argument misses the big picture.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> And I am not aware of free software ever following external corporate policies. What other company policies does free software follow?</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think you are misunderstanding or misrepresenting what happens. If the vendor no longer supports it, the number of users will drop dramatically. That makes porting to those systems useful for a smaller and smaller group of users. If some users continue using the systems without support, they should do the work of maintaining their own systems, including contributing to any free software they want to use.</div></div></blockquote><div><br></div><div>I think this argument has some merit, but we have to be careful. For example, Windows 7 still has 10% market share, while Linux desktop has 5% to 7% market share. I think it would be foolish to remove Windows 7 support just because Microsoft declared WIndows 7 obsolete. The market obviously disagrees.</div><div><br></div><div>And if we are using market share metrics as the yardstick, then Linux desktop support should be dropped before WIndows 7 support since Linux desktops represents fewer users by market share.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">The attitude that unpaid FOSS maintainers should do all the work to support obscure niche/proprietary systems is harmful to the ecosystem. </div></div></blockquote><div><br></div><div>FOSS maintainers already do all that unpaid work. A port to another piece of hardware or operating system is not a monumental leap. And given how often those [less frequently used] platforms uncover bugs, I think it is a worthwhile endeavor.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">(Obviously this doesn't mean maintainers can't do it if they choose to, for fun or education or whatever, they just shouldn't be expected to by default.)</div></div></blockquote><div><br></div><div>Jeff</div></div></div>