13 ms·

Linux Kernel Is Still Seeing Driver Work for the Macintosh II

187 points by caution 6y ago

Someone 6y ago
“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.” 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. Also, was the PS/2 keyboard/mouse interface any less proprietary than Apple Desktop Bus at time of initial release?
- protomyth 6y ago
  Yeah, ADB came first and NeXT implemented a version of it on their computers.
- LeoPanthera 6y ago
  The PS/2 interface was developed by IBM for their PS/2 range of computers, hence the name. "Personal System 2". The PS/2 was supposed to succeed the "PC", and was intentionally proprietary, to prevent clones. Despite their eventual failure, many technologies first introduced in the PS/2 range eventually became standards, including the 16550 UART (serial port), 1440 KB 3.5-inch floppy disk format, Model M keyboard layout, 72-pin SIMMs, the PS/2 keyboard and mouse ports, and the VGA video standard.
  - sergeykish 6y ago
    I never knew there was another layout https://en.wikipedia.org/wiki/Model_F_keyboard https://en.wikipedia.org/wiki/Model_F_keyboard
  - rbanffy 6y ago
    The inverted T model M, IIRC, was introduced in the 3151 terminal. Some time later, the RT/PC also had it. Even though they had the layout that has since dominated the industry, none of these had a PS/2 connector, since the PS/2 was only introduced in 1987.
- duskwuff 6y ago
  > Also, was the PS/2 keyboard/mouse interface any less proprietary than Apple Desktop Bus at time of initial release? Not really. They were both proprietary. ADB was Apple's solution, and PS/2 was IBM's solution. ADB was rather nifty from a technical perspective -- it was a multidrop bus which could support multiple devices, as opposed to PS/2 which could only support a single device per port. It was common for mice to be chained off of keyboards, for example, and there were a number of third-party peripherals which could be connected to ADB as well, like graphics tablets.
  - wolfgang42 6y ago
    ADB was basically USB 0.1: 5-volt multi-device serial bus for desktop peripherals, polled by the host, with dynamic addressing and standard device classes. The only thing it was missing was hot-plugging. (The protocol could handle it, but there were mechanical/electrical issues that made it hazardous to try.) They even had a connector that made it hard to tell if you were trying to plug it in upside down!
    - adrianmonk 6y ago
      With the connector itself, it was hard to tell, but the plastic part you held in your hand (molded plastic plus strain relief) wasn't symmetrical. You could thus develop a habit of putting, say, the flat part next to your thumb, and then you'd know the alignment of the cable. So if you knew the alignment of port, you could do reliably on the first attempt. USB makes a slightly worse mistake, which is that the plastic part you hold in your hand feels the same way if you turn it around 180 degrees. So you have to point it at your face and look at it if you want to know which way you're holding it.
      - twic 6y ago
        I think all of the USB-A jacks i have are made out of a sheet of metal folded over on itself, with the join on the bottom. You can tell which way up a jack is by looking for the join. See this picture of some random bitcoin gizmo: https://www.ccn.com/wp-content/uploads/2014/11/usb-top-bottom-together.png https://www.ccn.com/wp-content/uploads/2014/11/usb-top-botto... It's certainly not as easy as with ADB, but it only takes a quick glance to orient a USB jack. I can't be the only person to have noticed this.
- dreamcompiler 6y ago
  Also ironic: While Apple didn't invent USB, they were the first PC manufacturer to adopt it in a big way which led to it becoming commonplace everywhere.
  - stinos 6y ago
    That makes it sound like their adoption was the main cause for it becoming widespread. Do you have a source to back that up? It's just not how I remember it, but that might be my memory failing and/or being warped.
    - blincoln 6y ago
      This is just an anecdote, but in 1998-1999, the iMacs we bought where I worked were the first desktop systems I worked with that used USB[1]. My PC at the time used PS/2 for the keyboard and mouse, SCSI for external storage, a PC joystick port for game controllers, RS-232 for the first 8-port MIDI interface I ever owned, and the parallel port for my printer. I didn't migrate to mostly-USB until probably five years later, because I had plenty of non-USB hardware that still worked perfectly, and USB 1.x was slow. Mac users didn't really have that option, so I can certainly believe claims that they were one of (if not the) main drivers of USB. [1] ...and, apparently, the first desktop systems that relied exclusively on USB (https://en.wikipedia.org/wiki/Legacy-free_PC https://en.wikipedia.org/wiki/Legacy-free_PC).
      - bluedino 6y ago
        Ironically it took Firewire in addition to USB for the Mac to free itself from legacy ports. SCSI, for instance, wasn't able to run over USB.
        dreamcompiler 6y ago
        Indeed. And for people who assume USB's success was due to the iPod, remember that the first iPods were Firewire-only. By the time iPods adopted USB, USB was already popular.
- bitwize 6y ago
  The open solution was RS-232, which Macs of the era didn't support without extension hardware. PCs did not normally use RS-232 for keyboards, but up through the late 90s they often used them for mice.
  - duskwuff 6y ago
    Macs did support RS-232, via the MiniDIN-8 "printer" and "modem" ports. This port didn't supply power, though, making it a poor choice for a mouse or keyboard. (Serial mice typically got away with drawing power from one of the signal pins. This was a pretty gross hack, but it worked well enough.)
    - Someone 6y ago
      The Mac technically had RS-422 (https://en.wikipedia.org/wiki/RS-422#Applicationsj https://en.wikipedia.org/wiki/RS-422#Applicationsj, which allowed for much higher data speeds and larger cable lengths, but could be used as RS-232, too.
      - rvense 6y ago
        The Mac serial ports were much better than PC serial parts. They ran faster and could be used over longer distances and had hardware support for networking with those cheap LocalTalk boxes - as I understand it, you're basically physically daisy chaining the computers, and the hardware is capable of looking at a packet and decide whether it's for this computer and if isn't it can pass it on without software intervention.
- pengaru 6y ago
  Finding specifically that between the lines says more about your biases than the hidden implications. You seem focused on defending the reputation of Apple when pointing out the interface as proprietary is as much about highlighting the fact that a driver exists for it despite being proprietary as it is about disparaging uncooperative hardware vendors. The entire tone of the article is basically "The Linux kernel is so amazing not only is it still maintaining support for ancient hardware, it's proprietary hardware (and what I read between the lines is likely reverse engineered by volunteers) as well!"
  - wolfgang42 6y ago
    > likely reverse engineered Probably some of this had to be done (specs never quite match implementation), but the ADB protocol and hardware interface was quite well documented by Apple in Inside Macintosh and Guide to Macintosh Hardware which I’m sure the Linux devs availed themselves of. There was also an Apple KB article (written mostly for hardware and driver developers) with the charming title of “Help! Space Aliens Ate My Mouse!” which detailed all of the things that could go wrong with ADB that Apple hadn’t thought of when they wrote the original documentation.
- cat199 6y ago
  more fundamentally, no one focused on cross-platform input device 'standards' at that time, so the suggestion itself is a bit of an anachronism. I'm pretty sure every hardware platform had its own standard, and there were more desktop/workstation platforms then (Amiga, NeXT, Sun, SGI, etc)
  - jeffbee 6y ago
    Many SGI systems came with PS/2 keyboard and mouse ports. Other SGI systems (like the Indigo) came with PS/2-shaped DIN ports that just didn't work with PS/2 peripherals.
- cptskippy 6y ago
  What happened is pretty much par for the course when it comes to Apple, not to imply that there's anything wrong with what they do. They needed a solution and what was available was either woefully insufficient or non-existent so they developed a proprietary solution that met their needs. When an industry standard eventually provided a better option they moved (e.g. ADB -> USB). Most standards in the industry are bogged down by committees or designed to serve a myriad of use cases. Since Apple is vertically integrated and ships in volume, they generally don't have issues shipping proprietary solutions with very narrow use cases. Most of the negative messaging you hear around Apple's proprietary solutions are usually resentment from people who want but can't have it.
  - ryukafalz 6y ago
    > Most of the negative messaging you hear around Apple's proprietary solutions are usually resentment from people who want but can't have it. Speak for yourself. I would much prefer my iPhone to have a type-C port than the Lightning port it has; one less cable to keep track of.
    - cptskippy 6y ago
      I guess you missed where I said: > They needed a solution and what was available was either woefully insufficient or non-existent so they developed a proprietary solution that met their needs. Lightning is 8 years old and shipped in products 2 years before the USB-C specification was even finalized, 4 years before it was standardized. And it wasn't until 2018 that USB-C began being widely adopted. USB-C is still kind of a shit show in terms of compatibility, you can get a charger/cable combination that will charge one device and destroy another. Until that gets ironed out, Apple probably won't be using it in Phones.
duxup 6y ago
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?
Polylactic_acid 6y ago
Does the kernel ever remove support for devices or does this stuff just bloat up the codebase for eternity?
- ed25519FUUU 6y ago
  I was thinking the same thing. Is this actually “good” for Linux? This strikes more like a technical bar trick than an important part of the kernel, and another surface which can be attacked.
  - philwelch 6y ago
    I'm not a kernel expert but this seems like something that would be ISA-specific. If you're running a Linux kernel on anything other than a 68k processor, this code won't even be there for the most part. And if you are running it on a 68k, odds are you're running it on an old Mac anyway.
    - yjftsjthsd-h 6y ago
      I doubt that it's per-ISA; it's probably by device or maybe bus/transport. That is, with the right adapter you should be able to plug an ADB keyboard into a normal x86 box and have it work, but Linux will only actually load a driver if 1. it's statically compiled in (rare unless you built your own kernel), 2. you explicitly load it (`modprobe foo`), or 3. you plug in a device that uses that driver. As a reference point, I know NetBSD explicitly decouples these things; if you plug a brand-new PCI device into any system with a PCI slot, NetBSD doesn't care that you're plugging ex. a Sun keyboard into a "PC" USB card in a PowerPC mac - it has a keyboard driver, a USB driver, a PCI driver, and all of them use the same internal interfaces regardless of where they originated. I assume Linux does it the same way, but I don't know explicitly.
      - philwelch 6y ago
        The driver code seems to be under “macintosh/via-macii”, for whatever that’s worth.
stx 6y ago
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? It can be a great learning experience though.
- coreai 6y ago
  You don’t need old hardware to verify the speed differences. If you just take a browser in i3wm on bare arch Linux install that will be faster than in windows10 on the same machine. At least snappier. It’s just significantly lower overheads in Linux because you can tailor to your needs and remove all bloat. Also windows GUI is just more taxing on the system compared to Linux so that is going to be better at rendering something like a simple browser. Linux is slightly faster in some benchmarks(like geek bench) but overall the differences are minor when comparing apples to apples. It’s things GUI related where Linux has the edge in performance and some of the recent games have for some reason performed better on Linux than Windows according to an LTT video which is due to some real interest and development in Linux gaming.
- waheoo 6y ago
  I think you answered your own question at the end there. Then again, my father in law still refuses to buy new computers and will literally run them til they blow out. So their is definitely someone out there keeping the thing running.
- weare138 6y ago
  Same here. In the late 90s when I started in tech I worked at this defunct consulting co. doing life cycle support at Motorola's corporate headquarters. They just threw away old hardware so I scored some old Macs and a Next pizza box. My first experience with Linux was running it on some m68k Macs I saved from the trash compactor. Later I salvaged enough parts to get a couple PowerPC Macs running and installed Debian on them. I turned one into a firewall/router and ran a web server on the other. Repurposing old hardware was kind of like our generations equivalent to buying a Raspberry Pi. :)
Hydraulix989 6y ago
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.
- LukeShu 6y ago
  They keep things around as long as someone is using it and someone is willing to maintain it. Apparently, there are still nerds out there willing to maintain the Mac II support, but none willing to maintain the 386 support.
- skissane 6y ago
  My speculations: (1) there are people who are so keen on keeping 68K/Macintosh/etc support alive that they keep on working on it, while maybe no one displayed the same keenness when it came to 386 (2) 386 complicates code paths for 32-bit x86, which people still care about (even if only a little) for real world production use. By contrast, 68K stuff sits in its own directory tree and has little impact on the rest of the kernel
  - zozbot234 6y ago
    > (2) 386 complicates code paths for 32-bit x86, which people still care about (even if only a little) for real world production use. I don't know how much of a concern this is IRL, given that one could hide essentially all 386-specific workarounds behind #ifdef's.
    - innocenat 6y ago
      386 specific workaround code still needed to be updated if relevant part of the code is updated. If you look at the patch the remove 386 support (http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html), you can already see that it's already under #ifdef. There are quite a number of atomic instructions not available for 386 which all requires workaround.
cletus 6y ago
I have a question: doesn't all this extra (basically useless) driver code just increase the security risk for Linux? Like aren't you just increasing the attack surface? Since all these drivers exist in kernelspace. 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: 1. Not included in the kernel and not included as a module. This is obviously excluded at source and is the safest; 2. Available as a module but not loaded by default; and 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). 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. Also, I'm actually curious how often drivers are the source of security vulnerabilities? Is this a common or rare vector?
- duskwuff 6y ago
  The driver in question can't even be compiled for x86 systems, either as a module or otherwise. Having it in the source tree is completely harmless.
  - cbmuser 6y ago
    Exactly. It's arch-specific code. It won't even show up in the kernel configuration unless the architecture is m68k.
  - cletus 6y ago
    That misses the point entirely. It’s not about this driver specifically but concerns the thousands of other “dead” drivers and similar that could be loaded.
    - wtallis 6y ago
      Most people use their distro's default kernel binaries, which tend to include only modules that are at least somewhat likely to be used by that distro's target audience. Nobody ships kernels with all modules compiled.
cbmuser 6y ago
The m68k port is well maintained and is one of the oldest Linux ports of all. 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. There is also ongoing work to support LLVM [1] and consequently Rust [2] on Motorola 68000. Disclaimer: I'm Debian's primary maintainer of the m68k port and I'm supporting a lot of these efforts directly or indirectly. > [1] https://github.com/M680x0/M680x0-mono-repo https://github.com/M680x0/M680x0-mono-repo > [2] https://github.com/glaubitz/rust/tree/m68k-linux https://github.com/glaubitz/rust/tree/m68k-linux
- winrid 6y ago
  Thank you!! By the way, just curious, what draws you to work on it? Edit: OP explains here: https://news.ycombinator.com/item?id=23675025 https://news.ycombinator.com/item?id=23675025
  - cbmuser 6y ago
    I have been a long-time Amiga user (since the 90s) and never let go of the machine - like many others in the community (we even have regular conferences and meetings etc with new hardware being developed and released). I personally became the m68k maintainer in Debian because I was asked whether I would like to work on the port shortly after I became a Debian Developer and I agreed. I learned really a lot about kernel and software development in general that I stayed with it. It also helped me land a job with one of the big Linux companies.
- DCKing 6y ago
  I have a hardware question. Seeing that the heyday of the Motorola 68000 series was in the early nineties, aren't modern Debian's storage and memory requirements getting to be very prohibitive, even for a minimal headless install? I'm just curious what kind of hardware setups are used for running and developing Debian on these systems. What are you running on/developing with? Is a desktop computer with qemu the fastest practical 68k computer you can have?
rjsw 6y ago
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. 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.
whoopdedo 6y ago
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. (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.) [1] http://www.vgamuseum.info/index.php/component/k2/item/465-tseng-et6000 http://www.vgamuseum.info/index.php/component/k2/item/465-ts...
- jeffbee 6y ago
  Nice. A Rage128 or a Matrox Millenium are also good options for server graphics.
- rvense 6y ago
  USB->ADB adapters are more like ADB->USB translators than ADB on a USB bus, though. They'll only support some peripherals, and they'll show up as normal HID devices. You won't be able to connect your PageMaker dongle, unfortunately.
eyesee 6y ago
Here's a fun story about the creation of ADB by Woz: https://eggfreckles.net/2013/12/27/adb-the-epitome-of-early-apple/ https://eggfreckles.net/2013/12/27/adb-the-epitome-of-early-...

187 points by caution 6y ago

“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.” 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. Also, was the PS/2 keyboard/mouse interface any less proprietary than Apple Desktop Bus at time of initial release?

protomyth 6y ago
Yeah, ADB came first and NeXT implemented a version of it on their computers.
LeoPanthera 6y ago
The PS/2 interface was developed by IBM for their PS/2 range of computers, hence the name. "Personal System 2". The PS/2 was supposed to succeed the "PC", and was intentionally proprietary, to prevent clones. Despite their eventual failure, many technologies first introduced in the PS/2 range eventually became standards, including the 16550 UART (serial port), 1440 KB 3.5-inch floppy disk format, Model M keyboard layout, 72-pin SIMMs, the PS/2 keyboard and mouse ports, and the VGA video standard.
- sergeykish 6y ago
  I never knew there was another layout https://en.wikipedia.org/wiki/Model_F_keyboard https://en.wikipedia.org/wiki/Model_F_keyboard
- rbanffy 6y ago
  The inverted T model M, IIRC, was introduced in the 3151 terminal. Some time later, the RT/PC also had it. Even though they had the layout that has since dominated the industry, none of these had a PS/2 connector, since the PS/2 was only introduced in 1987.
duskwuff 6y ago
> Also, was the PS/2 keyboard/mouse interface any less proprietary than Apple Desktop Bus at time of initial release? Not really. They were both proprietary. ADB was Apple's solution, and PS/2 was IBM's solution. ADB was rather nifty from a technical perspective -- it was a multidrop bus which could support multiple devices, as opposed to PS/2 which could only support a single device per port. It was common for mice to be chained off of keyboards, for example, and there were a number of third-party peripherals which could be connected to ADB as well, like graphics tablets.
- wolfgang42 6y ago
  ADB was basically USB 0.1: 5-volt multi-device serial bus for desktop peripherals, polled by the host, with dynamic addressing and standard device classes. The only thing it was missing was hot-plugging. (The protocol could handle it, but there were mechanical/electrical issues that made it hazardous to try.) They even had a connector that made it hard to tell if you were trying to plug it in upside down!
  - adrianmonk 6y ago
    With the connector itself, it was hard to tell, but the plastic part you held in your hand (molded plastic plus strain relief) wasn't symmetrical. You could thus develop a habit of putting, say, the flat part next to your thumb, and then you'd know the alignment of the cable. So if you knew the alignment of port, you could do reliably on the first attempt. USB makes a slightly worse mistake, which is that the plastic part you hold in your hand feels the same way if you turn it around 180 degrees. So you have to point it at your face and look at it if you want to know which way you're holding it.
    - twic 6y ago
      I think all of the USB-A jacks i have are made out of a sheet of metal folded over on itself, with the join on the bottom. You can tell which way up a jack is by looking for the join. See this picture of some random bitcoin gizmo: https://www.ccn.com/wp-content/uploads/2014/11/usb-top-bottom-together.png https://www.ccn.com/wp-content/uploads/2014/11/usb-top-botto... It's certainly not as easy as with ADB, but it only takes a quick glance to orient a USB jack. I can't be the only person to have noticed this.
dreamcompiler 6y ago
Also ironic: While Apple didn't invent USB, they were the first PC manufacturer to adopt it in a big way which led to it becoming commonplace everywhere.
- stinos 6y ago
  That makes it sound like their adoption was the main cause for it becoming widespread. Do you have a source to back that up? It's just not how I remember it, but that might be my memory failing and/or being warped.
  - blincoln 6y ago
    This is just an anecdote, but in 1998-1999, the iMacs we bought where I worked were the first desktop systems I worked with that used USB[1]. My PC at the time used PS/2 for the keyboard and mouse, SCSI for external storage, a PC joystick port for game controllers, RS-232 for the first 8-port MIDI interface I ever owned, and the parallel port for my printer. I didn't migrate to mostly-USB until probably five years later, because I had plenty of non-USB hardware that still worked perfectly, and USB 1.x was slow. Mac users didn't really have that option, so I can certainly believe claims that they were one of (if not the) main drivers of USB. [1] ...and, apparently, the first desktop systems that relied exclusively on USB (https://en.wikipedia.org/wiki/Legacy-free_PC https://en.wikipedia.org/wiki/Legacy-free_PC).
    - bluedino 6y ago
      Ironically it took Firewire in addition to USB for the Mac to free itself from legacy ports. SCSI, for instance, wasn't able to run over USB.
      - dreamcompiler 6y ago
        Indeed. And for people who assume USB's success was due to the iPod, remember that the first iPods were Firewire-only. By the time iPods adopted USB, USB was already popular.
bitwize 6y ago
The open solution was RS-232, which Macs of the era didn't support without extension hardware. PCs did not normally use RS-232 for keyboards, but up through the late 90s they often used them for mice.
- duskwuff 6y ago
  Macs did support RS-232, via the MiniDIN-8 "printer" and "modem" ports. This port didn't supply power, though, making it a poor choice for a mouse or keyboard. (Serial mice typically got away with drawing power from one of the signal pins. This was a pretty gross hack, but it worked well enough.)
  - Someone 6y ago
    The Mac technically had RS-422 (https://en.wikipedia.org/wiki/RS-422#Applicationsj https://en.wikipedia.org/wiki/RS-422#Applicationsj, which allowed for much higher data speeds and larger cable lengths, but could be used as RS-232, too.
    - rvense 6y ago
      The Mac serial ports were much better than PC serial parts. They ran faster and could be used over longer distances and had hardware support for networking with those cheap LocalTalk boxes - as I understand it, you're basically physically daisy chaining the computers, and the hardware is capable of looking at a packet and decide whether it's for this computer and if isn't it can pass it on without software intervention.
pengaru 6y ago
Finding specifically that between the lines says more about your biases than the hidden implications. You seem focused on defending the reputation of Apple when pointing out the interface as proprietary is as much about highlighting the fact that a driver exists for it despite being proprietary as it is about disparaging uncooperative hardware vendors. The entire tone of the article is basically "The Linux kernel is so amazing not only is it still maintaining support for ancient hardware, it's proprietary hardware (and what I read between the lines is likely reverse engineered by volunteers) as well!"
- wolfgang42 6y ago
  > likely reverse engineered Probably some of this had to be done (specs never quite match implementation), but the ADB protocol and hardware interface was quite well documented by Apple in Inside Macintosh and Guide to Macintosh Hardware which I’m sure the Linux devs availed themselves of. There was also an Apple KB article (written mostly for hardware and driver developers) with the charming title of “Help! Space Aliens Ate My Mouse!” which detailed all of the things that could go wrong with ADB that Apple hadn’t thought of when they wrote the original documentation.
cat199 6y ago
more fundamentally, no one focused on cross-platform input device 'standards' at that time, so the suggestion itself is a bit of an anachronism. I'm pretty sure every hardware platform had its own standard, and there were more desktop/workstation platforms then (Amiga, NeXT, Sun, SGI, etc)
- jeffbee 6y ago
  Many SGI systems came with PS/2 keyboard and mouse ports. Other SGI systems (like the Indigo) came with PS/2-shaped DIN ports that just didn't work with PS/2 peripherals.
cptskippy 6y ago
What happened is pretty much par for the course when it comes to Apple, not to imply that there's anything wrong with what they do. They needed a solution and what was available was either woefully insufficient or non-existent so they developed a proprietary solution that met their needs. When an industry standard eventually provided a better option they moved (e.g. ADB -> USB). Most standards in the industry are bogged down by committees or designed to serve a myriad of use cases. Since Apple is vertically integrated and ships in volume, they generally don't have issues shipping proprietary solutions with very narrow use cases. Most of the negative messaging you hear around Apple's proprietary solutions are usually resentment from people who want but can't have it.
- ryukafalz 6y ago
  > Most of the negative messaging you hear around Apple's proprietary solutions are usually resentment from people who want but can't have it. Speak for yourself. I would much prefer my iPhone to have a type-C port than the Lightning port it has; one less cable to keep track of.
  - cptskippy 6y ago
    I guess you missed where I said: > They needed a solution and what was available was either woefully insufficient or non-existent so they developed a proprietary solution that met their needs. Lightning is 8 years old and shipped in products 2 years before the USB-C specification was even finalized, 4 years before it was standardized. And it wasn't until 2018 that USB-C began being widely adopted. USB-C is still kind of a shit show in terms of compatibility, you can get a charger/cable combination that will charge one device and destroy another. Until that gets ironed out, Apple probably won't be using it in Phones.

duxup 6y ago

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?

Polylactic_acid 6y ago

Does the kernel ever remove support for devices or does this stuff just bloat up the codebase for eternity?

ed25519FUUU 6y ago
I was thinking the same thing. Is this actually “good” for Linux? This strikes more like a technical bar trick than an important part of the kernel, and another surface which can be attacked.
- philwelch 6y ago
  I'm not a kernel expert but this seems like something that would be ISA-specific. If you're running a Linux kernel on anything other than a 68k processor, this code won't even be there for the most part. And if you are running it on a 68k, odds are you're running it on an old Mac anyway.
  - yjftsjthsd-h 6y ago
    I doubt that it's per-ISA; it's probably by device or maybe bus/transport. That is, with the right adapter you should be able to plug an ADB keyboard into a normal x86 box and have it work, but Linux will only actually load a driver if 1. it's statically compiled in (rare unless you built your own kernel), 2. you explicitly load it (`modprobe foo`), or 3. you plug in a device that uses that driver. As a reference point, I know NetBSD explicitly decouples these things; if you plug a brand-new PCI device into any system with a PCI slot, NetBSD doesn't care that you're plugging ex. a Sun keyboard into a "PC" USB card in a PowerPC mac - it has a keyboard driver, a USB driver, a PCI driver, and all of them use the same internal interfaces regardless of where they originated. I assume Linux does it the same way, but I don't know explicitly.
    - philwelch 6y ago
      The driver code seems to be under “macintosh/via-macii”, for whatever that’s worth.

stx 6y ago

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? It can be a great learning experience though.

coreai 6y ago
You don’t need old hardware to verify the speed differences. If you just take a browser in i3wm on bare arch Linux install that will be faster than in windows10 on the same machine. At least snappier. It’s just significantly lower overheads in Linux because you can tailor to your needs and remove all bloat. Also windows GUI is just more taxing on the system compared to Linux so that is going to be better at rendering something like a simple browser. Linux is slightly faster in some benchmarks(like geek bench) but overall the differences are minor when comparing apples to apples. It’s things GUI related where Linux has the edge in performance and some of the recent games have for some reason performed better on Linux than Windows according to an LTT video which is due to some real interest and development in Linux gaming.
waheoo 6y ago
I think you answered your own question at the end there. Then again, my father in law still refuses to buy new computers and will literally run them til they blow out. So their is definitely someone out there keeping the thing running.
weare138 6y ago
Same here. In the late 90s when I started in tech I worked at this defunct consulting co. doing life cycle support at Motorola's corporate headquarters. They just threw away old hardware so I scored some old Macs and a Next pizza box. My first experience with Linux was running it on some m68k Macs I saved from the trash compactor. Later I salvaged enough parts to get a couple PowerPC Macs running and installed Debian on them. I turned one into a firewall/router and ran a web server on the other. Repurposing old hardware was kind of like our generations equivalent to buying a Raspberry Pi. :)

Hydraulix989 6y ago

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.

LukeShu 6y ago
They keep things around as long as someone is using it and someone is willing to maintain it. Apparently, there are still nerds out there willing to maintain the Mac II support, but none willing to maintain the 386 support.
skissane 6y ago
My speculations: (1) there are people who are so keen on keeping 68K/Macintosh/etc support alive that they keep on working on it, while maybe no one displayed the same keenness when it came to 386 (2) 386 complicates code paths for 32-bit x86, which people still care about (even if only a little) for real world production use. By contrast, 68K stuff sits in its own directory tree and has little impact on the rest of the kernel
- zozbot234 6y ago
  > (2) 386 complicates code paths for 32-bit x86, which people still care about (even if only a little) for real world production use. I don't know how much of a concern this is IRL, given that one could hide essentially all 386-specific workarounds behind #ifdef's.
  - innocenat 6y ago
    386 specific workaround code still needed to be updated if relevant part of the code is updated. If you look at the patch the remove 386 support (http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html), you can already see that it's already under #ifdef. There are quite a number of atomic instructions not available for 386 which all requires workaround.

cletus 6y ago

I have a question: doesn't all this extra (basically useless) driver code just increase the security risk for Linux? Like aren't you just increasing the attack surface? Since all these drivers exist in kernelspace. 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: 1. Not included in the kernel and not included as a module. This is obviously excluded at source and is the safest; 2. Available as a module but not loaded by default; and 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). 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. Also, I'm actually curious how often drivers are the source of security vulnerabilities? Is this a common or rare vector?

duskwuff 6y ago
The driver in question can't even be compiled for x86 systems, either as a module or otherwise. Having it in the source tree is completely harmless.
- cbmuser 6y ago
  Exactly. It's arch-specific code. It won't even show up in the kernel configuration unless the architecture is m68k.
- cletus 6y ago
  That misses the point entirely. It’s not about this driver specifically but concerns the thousands of other “dead” drivers and similar that could be loaded.
  - wtallis 6y ago
    Most people use their distro's default kernel binaries, which tend to include only modules that are at least somewhat likely to be used by that distro's target audience. Nobody ships kernels with all modules compiled.

cbmuser 6y ago

The m68k port is well maintained and is one of the oldest Linux ports of all. 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. There is also ongoing work to support LLVM [1] and consequently Rust [2] on Motorola 68000. Disclaimer: I'm Debian's primary maintainer of the m68k port and I'm supporting a lot of these efforts directly or indirectly. > [1] https://github.com/M680x0/M680x0-mono-repo https://github.com/M680x0/M680x0-mono-repo > [2] https://github.com/glaubitz/rust/tree/m68k-linux https://github.com/glaubitz/rust/tree/m68k-linux

winrid 6y ago
Thank you!! By the way, just curious, what draws you to work on it? Edit: OP explains here: https://news.ycombinator.com/item?id=23675025 https://news.ycombinator.com/item?id=23675025
- cbmuser 6y ago
  I have been a long-time Amiga user (since the 90s) and never let go of the machine - like many others in the community (we even have regular conferences and meetings etc with new hardware being developed and released). I personally became the m68k maintainer in Debian because I was asked whether I would like to work on the port shortly after I became a Debian Developer and I agreed. I learned really a lot about kernel and software development in general that I stayed with it. It also helped me land a job with one of the big Linux companies.
DCKing 6y ago
I have a hardware question. Seeing that the heyday of the Motorola 68000 series was in the early nineties, aren't modern Debian's storage and memory requirements getting to be very prohibitive, even for a minimal headless install? I'm just curious what kind of hardware setups are used for running and developing Debian on these systems. What are you running on/developing with? Is a desktop computer with qemu the fastest practical 68k computer you can have?

rjsw 6y ago

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. 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.

whoopdedo 6y ago

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. (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.) [1] http://www.vgamuseum.info/index.php/component/k2/item/465-tseng-et6000 http://www.vgamuseum.info/index.php/component/k2/item/465-ts...

jeffbee 6y ago
Nice. A Rage128 or a Matrox Millenium are also good options for server graphics.
rvense 6y ago
USB->ADB adapters are more like ADB->USB translators than ADB on a USB bus, though. They'll only support some peripherals, and they'll show up as normal HID devices. You won't be able to connect your PageMaker dongle, unfortunately.

eyesee 6y ago

Here's a fun story about the creation of ADB by Woz: https://eggfreckles.net/2013/12/27/adb-the-epitome-of-early-apple/ https://eggfreckles.net/2013/12/27/adb-the-epitome-of-early-...