The m68k port is well maintained and is one of the oldest Linux ports of all.<p>There are multiple active kernel maintainers and the port is regularly seeing improvements and new drivers such as for the X-Surf 100 ethernet card for the Amiga or the ICY board (an I2C board) for the Amiga.<p>There is also ongoing work to support LLVM [1] and consequently Rust [2] on Motorola 68000.<p>Disclaimer: I'm Debian's primary maintainer of the m68k port and I'm supporting a lot of these efforts directly or indirectly.<p>> [1] <a href="https://github.com/M680x0/M680x0-mono-repo" rel="nofollow">https://github.com/M680x0/M680x0-mono-repo</a><p>> [2] <a href="https://github.com/glaubitz/rust/tree/m68k-linux" rel="nofollow">https://github.com/glaubitz/rust/tree/m68k-linux</a>
<i>“Apple Desktop Bus is the proprietary interface used by Apple in the late 80's and 90's for connecting devices like keyboards and mice to the system rather than a PS/2 interface.”</i><p>The implication (between the lines) that Apple went with a proprietary solution while an open one was available bends history a bit. Judging by release date, ADB predates PS/2 by half a year or so.<p>Also, was the PS/2 keyboard/mouse interface any less proprietary than Apple Desktop Bus at time of initial release?
Back in the early 2000s I did not have much money and but was able to get my hands on all sorts of slightly exotic and out of date computers for free. People just gave them away. I really enjoyed running Linux on old SGI or Apple computers. Over time however the novelty wore off and I realized that even old x86 hardware was cheaper and faster. Any people running Linux on some rare old hardware care to share why?<p>It can be a great learning experience though.
I had been meaning to see if anyone was interested in some fixes to the IOP ADB driver for the IIfx and some Quadra machines.<p>Apple had provided some internal documentation for the IOP controller but it is incorrect. The Linux driver for it just polls any ADB device for data directly instead of letting the IOP process it and just interrupt the CPU when there is a complete ADB message. I have got a working IOP driver for NetBSD/mac68k that the Linux people might like to copy.
Why is Macintosh II still being worked on but 386 support got killed? I genuinely want to know. I suppose it might be because 386 requires more gymnastics around systems programming for memory management, etc.
I was amusing myself with using obsolete tech with a modern computer this weekend when I needed a video card for a server. Not wanting to waste power on an unnecessary GPU I looked around for the least capable card I had and found one from 1997[1]. It still works fine with a processor made in 2017. And Linux had no complaints using the generic VESA X.org driver. Though there is a native Tseng driver still there, the particular live USB I had would segfault. Actually it looks like the last two bugs filed against it were marked WONTFIX in 2011 so I'd say the driver is unmaintained and Xorg should consider removing it.<p>(I wonder if the new ADB driver would be useful with the USB-to-ADB adapter I have. Although the only thing I could plug into it is a trackball.)<p>[1] <a href="http://www.vgamuseum.info/index.php/component/k2/item/465-tseng-et6000" rel="nofollow">http://www.vgamuseum.info/index.php/component/k2/item/465-ts...</a>
So is someone running the kernel on their Macintosh II... to do a thing (obviously as the article notes it was tested on a Centris 650) or is this just an awesome thing to do because it could be done?
Here's a fun story about the creation of ADB by Woz: <a href="https://eggfreckles.net/2013/12/27/adb-the-epitome-of-early-apple/" rel="nofollow">https://eggfreckles.net/2013/12/27/adb-the-epitome-of-early-...</a>
I have a question: doesn't all this extra (basically useless) driver code just increase the security risk for Linux?<p>Like aren't you just increasing the attack surface? Since all these drivers exist in kernelspace.<p>So there's three levels, as I understand it that driver code like this could be included (or not) in the kernel. This is not my area of expertise so please excuse me if I'm mistaken here but you have:<p>1. Not included in the kernel and not included as a module. This is obviously excluded at source and is the safest;<p>2. Available as a module but not loaded by default; and<p>3. Included in the kernel. I'm not 100% sure if there even is a distinction between this and (2) anymore. I remember at one point you could include code as part of the configure process during compilation and this was distinct from modules (at least for a time).<p>Either way, there doesn't seem to be a difference philosophically between (2) and (3), right? A vulnerable module can be loaded from userspace, generally speaking.<p>Also, I'm actually curious how often drivers are the source of security vulnerabilities? Is this a common or rare vector?