Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    The PowerBook 100 sub-notebook launched in 1991 with a 16MHz Motorola 68000 processor and up to 8MB of memory. In 2018, the Linux kernel is still receiving fixes/improvements for the PowerBook 100 series...

    http://www.phoronix.com/scan.php?pag...m68k-Powerbook

  • bridgman
    replied
    Originally posted by Hugh View Post
    We all wanted VAX-like systems (32-bit).
    Yep. I ended up jumping from 68000 to the National 16032, which was a very slick design with a good page-based MMU, but it took a lot longer than expected before it could run Unix and by that time the Intel 386 was out with 32-bit flat addressing and 8/16-bit back compatibility and that ate up a lot of the market.

    Leave a comment:


  • Hugh
    replied
    Originally posted by bridgman View Post

    I think most early 68xxx systems used custom HW for the MMU to get page-based rather than segment-based management.
    Yes.

    I remember waiting very impatiently for a microprocessor that could run UNIX. The largest missing piece was the MMU. It was as if the processor makers just didn't get it.

    The pioneers in the workstation business built their own solutions rather than waiting.

    We all wanted VAX-like systems (32-bit). Some of us would have made do with PDP-11-like systems (16-bit). Essentially all workstation companies went the VAX-like route.

    The Sun Microsystems MMU for the 68020 (and, I presume, the 68010) was a really effective MMU designed by Andy Bechtolsheim (a founder of Sun). It was quite a bit better than the eventual Motorola designs.

    The workstation world and the personal computer worlds took a long time to converge. That was completed when Windows started to have similar requirements to UNIX. I don't think that MacOS needed an MMU until OSX and and the first Windows that needed an MMU was Windows NT. I think that OS/2 was built around the Intel 286's MMU (16-bit, non-paging).

    Full scale 32-bit UNIX ran happily in 4M or less. I think I ran Linux on PCs with 4M of RAM. It is sad if Linux can no longer do so. Not important, just sad.

    Leave a comment:


  • agd5f
    replied
    Originally posted by monraaf View Post

    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 was being sarcastic

    Leave a comment:


  • bridgman
    replied
    Originally posted by chithanh View Post
    Or they didn't use any MMU at all, as it introduced additional wait states for memory access.
    Yeah, I should have said "most early 68xxx minicomputer systems" (typically running Unix).

    For embedded systems MMUs were pretty rare (early Macintoshes didn't use them either) - there's a school of thought that on-chip caches were introduced to compensate for the overhead of MMUs

    Leave a comment:


  • chithanh
    replied
    Originally posted by bridgman View Post
    I think most early 68xxx systems used custom HW for the MMU to get page-based rather than segment-based management.
    Or they didn't use any MMU at all, as it introduced additional wait states for memory access.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by monraaf View Post
    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.
    Again - it's not that black and white. The work done for this Powerbook isn't a waste of time for the developer who made it, but it is a waste of Linus' time to look at it.
    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.
    And if he's the one who merged it, rather than someone more busy than him (like Linus) then I see nothing wrong here.
    A modern kernel for a modern Debian unstable: https://cdimage.debian.org/cdimage/ports/
    I know that exists, but that doesn't specify whether it's being used by the devices in question.

    Leave a comment:


  • onicsis
    replied
    Originally posted by monraaf View Post

    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.

    Leave a comment:


  • onicsis
    replied
    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
    Last edited by onicsis; 04-03-2018, 09:22 PM.

    Leave a comment:


  • monraaf
    replied
    Originally posted by schmidtbag View Post
    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/

    Leave a comment:

Working...
X