In 2018, Linux Is Still Receiving Fixes For The Apple PowerBook 100 Series

[Michael]

Is this about PPC32? I thought basically one tiny distro still supported it, surprised to see anyone cares that much

This is pre-PPC Apple hardware.

[nanonyme]

This is pre-PPC Apple hardware.

Oh, well, I guess that's fine then as long as PPC32 dies out

[agd5f]

In private, yes. In a global project used by billions of devices in the world, absolutely not.

Then who gets to determine what is "ok" and what is "not ok"?

[agd5f]

I actually advocate for people who are under-represented. More often than not, I express support for hardware I don't own and never plan to. That being said, it isn't a matter of whether it caters to my interest; you're missing my point:
If this came down to just whoever maintains the m68k architecture and whoever made these patches, I wouldn't say anything. As pointed out by others, those people probably have the time and they're working on something they're passionate about, which I think is great, and I encourage them. The problem, however, is they're not the only ones involved. Linus himself was addressed in these fixes. Even if that's just 5 minutes of his time, it's important to consider how many commits and mergers he works with. It is objectively a waste of his time. I am not suggesting it is a waste of everyone's time.

That being said, if this got merged into the mainline kernel without involving Linus, Arlie, or any other major maintainers then great - no complaints from me.

I think are are treading a dangerous line. Are you saying we should discourage people from sending patches? That's one of the main ways people get involved in open source. Unless your patches are really good or are something that's considered "important", don't bother sending them, it's a waste of everyone's time. Who determines what is a waste of time? What if a legit bug gets found, but the developer is new and unsure of him/herself and doesn't want to waste anyone's time?

Also It goes both ways. The developer and the community have to engage. Someone in the community has to have enough interest in the patch to review it in first place. No one is forcing anyone to review patches.

[schmidtbag]

I think are are treading a dangerous line. Are you saying we should discourage people from sending patches? That's one of the main ways people get involved in open source. Unless your patches are really good or are something that's considered "important", don't bother sending them, it's a waste of everyone's time. Who determines what is a waste of time? What if a legit bug gets found, but the developer is new and unsure of him/herself and doesn't want to waste anyone's time?

Actually, it's not a dangerous line, but it seems that way because you choose to think in such black and white terms. There is a lot of gray area involved here.
No, I'm not saying we should discourage people from sending patches, I didn't even imply that.
I never said anything about everyone's time being wasted; only a select few. In fact, I explicitly stated that these patches aren't a waste of everyone's time.
If legit bugs are found, then yes, they should be patched, at least if the patch can realistically be expected to reach most of the targeted audience.

What I'm actually saying is you need to weigh the priorities as to whether the patch is wasting the time of people who don't have much to spare, such as Linus. In this case, this Powerbook has the following to consider:
* It is a very niche device by today's standards. To my understanding, these patches are specific to this device, not just any m68k device.
* Of the people who are still using this device, I'm willing to bet the majority of them are running an Apple-based OS, possibly BeOS, rather than Linux.
* Of this small minority who use this device with Linux, I'm willing to bet an even smaller percentage of them are running a modern kernel.
* What may be fewer than 100 people in the world running this device with a modern Linux kernel, how many of them do you think were actually seeking these patches?

So when you consider all of that, do you not see how this is a bad priority to bring to the attention of Linus, who is likely already backlogged with dozens, if not hundreds of commits? Why can't someone else do it? Remember - Linus was the one addressed here.

Meanwhile, if this was a patch that affected all m68k devices where it affected performance, security, or data integrity, I would consider that a good priority.

Also It goes both ways. The developer and the community have to engage. Someone in the community has to have enough interest in the patch to review it in first place. No one is forcing anyone to review patches.

Right, but if someone like Linus or Dave are the ones who have to accept these patches, how are they supposed to know what's actually relevant? By the time they figure out it isn't worth their attention, they already wasted too much time on it.

Think of the situation like this:
When you get a speeding ticket and want to contest it, would you go to the supreme court about it? Your ticket may be worthy of attention, but it's not important enough to bring to such a high level.

TL;DR
I'm not saying these patches should go ignored, but they're not worth Linus' attention.

[agd5f]

Actually, it's not a dangerous line, but it seems that way because you choose to think in such black and white terms. There is a lot of gray area involved here.
No, I'm not saying we should discourage people from sending patches, I didn't even imply that.
I never said anything about everyone's time being wasted; only a select few. In fact, I explicitly stated that these patches aren't a waste of everyone's time.
If legit bugs are found, then yes, they should be patched, at least if the patch can realistically be expected to reach most of the targeted audience.

What I'm actually saying is you need to weigh the priorities as to whether the patch is wasting the time of people who don't have much to spare, such as Linus. In this case, this Powerbook has the following to consider:
* It is a very niche device by today's standards. To my understanding, these patches are specific to this device, not just any m68k device.
* Of the people who are still using this device, I'm willing to bet the majority of them are running an Apple-based OS, possibly BeOS, rather than Linux.
* Of this small minority who use this device with Linux, I'm willing to bet an even smaller percentage of them are running a modern kernel.
* What may be fewer than 100 people in the world running this device with a modern Linux kernel, how many of them do you think were actually seeking these patches?

Maybe. Who knows? Who gets to make the determination on what is valuable or not as long as someone is still interested in maintaining them? Why not just remove 68000 processor support altogether?

So when you consider all of that, do you not see how this is a bad priority to bring to the attention of Linus, who is likely already backlogged with dozens, if not hundreds of commits? Why can't someone else do it? Remember - Linus was the one addressed here.

Meanwhile, if this was a patch that affected all m68k devices where it affected performance, security, or data integrity, I would consider that a good priority.


Right, but if someone like Linus or Dave are the ones who have to accept these patches, how are they supposed to know what's actually relevant? By the time they figure out it isn't worth their attention, they already wasted too much time on it.

Think of the situation like this:
When you get a speeding ticket and want to contest it, would you go to the supreme court about it? Your ticket may be worthy of attention, but it's not important enough to bring to such a high level.

TL;DR
I'm not saying these patches should go ignored, but they're not worth Linus' attention.

No one was asking Linus to review these patches. This was a pull request for the 4.17 merge window. For the most part, Linus relies on the maintainers for the relevant subsystems to handle all the patch reviews and integration. He doesn't review and commit each patch, he just takes the pull requests from all the subsystems. It's up to the relevant maintainer and developers to handle the reviews and branch integration. There's no way Linus could review each patch the goes into the kernel.

[monraaf]

Why not just remove 68000 processor support altogether?

Because the code is actively maintained and used and works well.

There are also new drivers for Linux/m68k in the works, namely zorro_esp and xsurf100. We have working LibreOffice, Thunderbird, Firefox, OpenJDK, gcc-8 with all features and build around 11000 out of 12900 binary packages in Debian.

Why on earth should we remove it? Just because some people on Phoronix think so? That's just laughable.

[monraaf]

If this came down to just whoever maintains the m68k architecture and whoever made these patches, I wouldn't say anything. As pointed out by others, those people probably have the time and they're working on something they're passionate about, which I think is great, and I encourage them. The problem, however, is they're not the only ones involved. Linus himself was addressed in these fixes. Even if that's just 5 minutes of his time, it's important to consider how many commits and mergers he works with. It is objectively a waste of his time. I am not suggesting it is a waste of everyone's time.

It's not a waste of time. Keeping code portable is an important task and building the Linux kernel on different architectures with different peculiarities helps maintaining portability.

That being said, if this got merged into the mainline kernel without involving Linus, Arlie, or any other major maintainers then great - no complaints from me.

The m68k port is maintained by Geert Uytterhoven, one of the most experienced kernel developers we have in Linux. If he sends a PR, Linus just accepts it because he trusts people like Geert.

Right, but this Macbook isn't industrial equipment, and these fixes are targeted toward the Macbook. I'm not speaking on behalf of the m68k maintainer's time; I'm sure whoever that is would be thrilled to see patches. As I said to agd5f, it's everyone above them who may be involved whose time is wasted.

Again, there is no waste of time. This is about portability. m68k is very peculiar in it's default alignment (16-bit) and the fact that it has a stronger separation of data and code in its registers.

Furthermore, you have to remember: this is a patch for the modern kernel. Most of this industrial equipment you speak of likely runs the 2.4 kernel or older. So, even if they could benefit from these patches, they probably won't.

A modern kernel for a modern Debian unstable: https://cdimage.debian.org/cdimage/ports/

[onicsis]

From experience, minimum memory requirement for qemu to boot is something over 384MB, lower than that the boot process will freeez mysteriously.

Minimum minimorum of a very lightweight modern Linux Desktop. From Tiny Core (Linux FAQ

---

What are the minimum requirements?


An absolute minimum of RAM is 46mb. TC won't boot with anything less, no matter how many terabytes of swap you have.
Microcore runs with 28mb of ram.
The minimum cpu is i486DX (486 with a math processor).

A recommended configuration:
Pentium 2 or better, 128mb of ram + some swap

And by comparison for Ubuntu Server

System Requirements

Ubuntu 16.04 LTS Server Edition supports three (3) major architectures: Intel x86, AMD64 and ARM. The table below lists recommended hardware specifications. Depending on your needs, you might manage with less than this. However, most users risk being frustrated if they ignore these suggestions. Recommended Minimum Requirements

Server (Standard)	1 gigahertz	512 megabytes	1.5 gigabyte	2.5 gigabytes
Server (Minimal)	300 megahertz	384 megabytes	1.5 megabytes	2.5 gigabytes

[onicsis]

Because the code is actively maintained and used and works well.

There are also new drivers for Linux/m68k in the works, namely zorro_esp and xsurf100. We have working LibreOffice, Thunderbird, Firefox, OpenJDK, gcc-8 with all features and build around 11000 out of 12900 binary packages in Debian.

Why on earth should we remove it? Just because some people on Phoronix think so? That's just laughable.

I will guess, other architectures will be added if someone express a real interest by providing patches and maintaining it. Actually it's a free software can be forked at any time, even for personal experimentation. For Risc-V no actual physicAL processors exists.