On Wed, 21 May 2025, John Klos wrote:
> > As I pointed out years ago, you need to stop wasting effort on > > packages that aren't relevant anymore, due to bloat. > > There's no real point being made here. Which packages aren't relevant > any more, due to bloat? Who decides? > Users do. I've said so several times. https://lists.debian.org/debian-68k/2023/08/msg00023.html https://lists.debian.org/debian-68k/2024/10/msg00024.html https://lists.debian.org/debian-68k/2024/11/msg00019.html > > And here's another thing you need to understand: there is no future > > for a port that has no porter willing to identify relevant packages > > and send patches upstream. > > This is a non sequitur. Reporting upstream is nice, but a port can exist > without stuff getting reported upstream. > > While Adrian is obviously emotionally committed to improving Linux on > m68k, the points he makes have reasoning, thought and explanations > behind them. None of the arguments from you, Finn, make much sense. > You're talking about irrelevant things and bringing nonsense examples in > to the discussion. Your examples lack technical merit. > Perhaps you can show me the technical shortcomings of the patch I sent to the python project? > The issue really boils down to this: > > Should Linux maintain a 32 bit platform that has alignment issues > because programmers make bad assumptions? > > Your argument is that ABI breakage is death, and that projects and the > world are better when we tell people to fix their broken code. > No, that's not what I said. > I agree that ABI breakage is a huge hurdle. At the same time, the ABI > will change to fix 32 bit time. Is there any good reason to NOT switch > to 32 bit alignment at the same time the time changes are made? I can't > think of any reason. > > So can we all agree that there's no reason to not change alignment when > the time changes are done? > We've been over that before too: https://lists.debian.org/debian-68k/2023/08/msg00023.html > Next, I also agree that programmers should not make padding assumptions. > However, the real world shows us that there are way too many gatekeepers > who scoff at the idea of supporting anything that's not Arm, amd64, or > perhaps RISC-V. They don't care if their bad assumptions about floating > point affect embedded platforms. They don't care if they've assumed that > nothing of interest ever runs on big endian systems. Heck - they > sometimes don't even care if things no longer compile or run properly on > 32 bit x86! > > Dealing with them is tedious. Sometimes a private email to the right > person in a project leads to a proper fix, and we don't even have to > publicly talk about the fact that the failure was on m68k, VAX, Alpha, > or whatever. > > I've done enough of this to know that it's far, far better a spend of my > time to make things work by default where possible, and if not, to > maintain local patches with an email sent off to good people so the > gatekeepers can be avoided. > > If you think that the work of getting projects to care about edge cases > isn't hard, then good for you - perhaps you should volunteer to do it. I did that already: https://lists.debian.org/debian-68k/2024/10/msg00042.html > But at the same time I've seen you say you don't need and arent > interested in these fancy new languages and packages, so I can't see you > volunteering to do it. > > So if you're not going to volunteer yourself, then it's not really your > place to suggest to others that they should be doing it instead of > taking the easier route, which is to make more things work by default. > > > But, if it's not already dead, you will kill Debian/m68k if you break > > the ABI contract. > > It's frustrating that you'd write this. > > Are there so few fans of m68k that this will kill Debian/m68k? Once the ABI fragments, there is no "Linux/m68k" any longer. There are isolated groups of users/developers with limited ability to collaborate effectively. > If so, then the 64 bit time change will kill Debian/m68k, and there's > nothing anyone can do about it. So are you saying that the death of > Debian/m68k is inevitable, and that we should all just give up? Anyone > who still wants to run a modern OS on m68k hardware can still run > NetBSD, after all. Right? > > Or maybe this WON'T kill Debian/m68k. And if it won't, then making two > ABI changes at the same time is no different than making one. Right? So > why not make the default alignment for m68k fit what programmers, who we > all agree really shouldn't be assuming, assume for 32 bit so more things > Just Work? > > I see absolutely no compelling reason given by you or anyone else about > why this shouldn't be done aside from ABI change, and if if the ABI is > about to change for time, then that reason becomes moot, doesn't it? > > Or do you or anyone else have a reason why it's not moot? > As I've said, I'm okay with a Gentoo/m68k profile for ABI experimentation as long as the default profile tracks the upstream toolchain: https://lists.debian.org/debian-68k/2024/10/msg00045.html > > Nevermind removing that characteristic which provides it with a unique > > advantage, being a smaller memory and cache footprint. > > This is ridiculous handwaving. > > If the memory footprint of software goes up enough to matter because of > 32 bit instead of 16 bit alignment, then perhaps someone should tell > people running the NetBSD/sun2 port. The very latest NetBSD runs on > m68010 systems with actual 16 bit data busses in 4 megabytes of memory > with 32 bit alignment. Think about all the memory they could save! > > Ok. That was a bit snarky, but do you really expect anyone to take this > seriously? > Well, your handwaving is no more convincing than mine. Measurements are welcome, though it's hard to know which hardware designs to measure. > Likewise, do you really think that the overhead of unaligned access is > outweighed by the fact that more stuff fits in the cache? Seriously? > Yes, some of my 68030 systems have 16-bit data busses. As for the ones with 32-bit busses, I'd expect that two cache accesses are generally faster than a long-word-aligned RAM access, though you may be right about those algorithms that miss the cache. BTW, my Apple Workgroup Server 95 has 512 KB of L2 cache. If I can get Linux to run on it, I think it might provide some interesting measurements. > > Try to see the big picture. All ports will suffer the same fate as > > this one: fewer users, commercial irrelevance, reluctant contributors > > and bloated packages. > > What does any of this have to do with fixing alignment on m68k? > > > The relevance of m68k is now the way in which we respond to those > > challenges. If the best that any port can hope for is ABI breakage, > > we've failed. > > Are you here advocating for the termination of Debian/m68k? Or are you > saying that alignment shouldn't be updated, and time shouldn't be > updated? I really don't understand what you're suggesting. > > > One does not age gracefully by pretending to be young. m68k does not > > contribute anything by becoming the same as every other 32-bit > > big-endian platform. > > This is nonsense. It is the main reason why porting to m68k leads to better code. > The natural alignment for m68020, m68030, m68040, m68060 is 32 bit. That > Linux didn't follow the SVR4 spec for ELF was an error. > > I really want to know: > > Who gets to make the call about whether or not the change is made? > Those with the time and skills to write the patches and the ability to push them upstream to all the affected projects. Same as always.
