Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hey Joseph? #63

Open
mgederberg opened this issue Aug 17, 2022 · 22 comments
Open

Hey Joseph? #63

mgederberg opened this issue Aug 17, 2022 · 22 comments

Comments

@mgederberg
Copy link

Hey Joseph, I hope you are well? So now that I pretty much have my Apple //e's built out the way I want, I have begun the process of configuring this A2SERVER stuff. Ivan X's site is down but before it went bye bye, I managed to grab the RasappleII image as a Wheezy Distro and yeah I got it running. However, Tight VNC server will not install as expected anymore due to broken links and it would be a nice to have since for the most part my pi will be headless unless using the Apple II pi stuff. Now I really wanna get a build running as expected with Buster for all the stuff that is working on the Wheezy distro I have as an image 'cause Buster is now the "official" Raspbian legacy OS. image it and be done so I always have a backup that I can restore without the headaches of broken links. I will eventually be procuring a Pi card for my //e and if all is cool with the testing, I can use my super serial card for other stuff. Hell, if it works I will try and scare up another 2 cards for my other earlier Apple II and my IIGS. Is there a buster image out there I can work with quicker than having to piece this all together as you've suggested here? Having the LinApple, GS emu and the server stuff all working would be MORE than handy for my museum I am building here in my lab. Many thanks brother!

@knghtbrd
Copy link
Member

Hi! Sorry for the delay getting back to you—I've been a bit under the weather the past couple of days and your issues got buried in the stack.

This project (or rather I should say these projects) fell off the rails a bit because of a number of reasons. Some of them are totally my fault. Others are a little complicated. The TL;DR version is that at this point I've kind of got to rebuild a lot of things from scratch. Which is fine, I'm interested in doing that. The question is … what to build? I don't really use social media at all anymore, so I'm pretty far out of touch with what users are looking for.

The first reason I've gotta build it from scratch is that Ivan's build script for the whole kit and kaboodle was a bash "history" file. The idea was he'd install Raspbian Wheezy or a Debian Wheezy virtual machine in VirtualBox, and then he'd load this file in containing like 47 command lines (they were numbered) and you'd run each one in turn. Sometimes you had to reboot between steps (not really documented, but I have an email somewhere that tells me which ones.) These command lines were all one line code blocks with if-then-else statements, etc., and by the time I was trying to use it Raspbian had changed things so it didn't work right anymore. Like specific Broadcom firmware and partition map and bootloader changes. Hoo boy. So I didn't have a single baseline. 😬 I could probably have made sense of it if I knew then some of what I know now.

Plus the scripts spat out tons of errors that just flew by unchecked, and at least some of those were important, leading to broken installations. Much effort was made trying to clean that up, sort it out, maybe migrate to using Debian packages for things, do it "the right way" so other people could step in and help with things beyond my skill, etc. These hit walls a few times, and I kind of felt like there wasn't really any interest in it—certainly it didn't seem like there was any from people who were in a position to help make stuff work that I was struggling with.

If that sounds bleak … it isn't necessarily. There's multiple projects involved as I said before, and some of them are more approachable today than others, but they're all somewhere within the realm of possibility. Here's the components that existed in the big image you downloaded:

  • Customized Raspbian
  • A combination of Apple II compatible netatalk and samba
  • An ADTPro server
  • Virtual serial disk drives using ADTPro
  • A couple of Apple II emulators
  • Dave Schmenk's Apple II Pi software
  • A serial terminal hopefully set up for Apple II use
  • A utility disk for ProDOS systems to interface all of the above

Dave Schmenk kinda wanted to do his own thing with the Apple II Pi software that basically turned an Apple IIc into a 20MHz "IIgs", let you access your Apple II disk drives from Linux, etc. It was only ever lumped in with our stuff because at the time Ivan's thing became the catch-all for Apple II and Raspberry Pi projects. That removed the hard requirement for Apple II emulators on Linux (since that's why they were there…) I didn't want to remove them because, um, I use Linux and I occasionally like having an emulator on hand! 😃

That leaves a bit customized Raspberry Pi installer (which I know how to do now), some custom stuff for a serial terminal and maybe a friendlier Linux shell environment, the ADTPro stuff, and the AppleTalk + SMB file server. That's a lot, but most of it should not be too crazy difficult, especially if I start with stuff people actually want to use.

And actually, going beyond what the old a2server or a2cloud did with those things is possible if there's enough interest. Some of it's going to require code, though, and I don't yet know how to write some of it particularly for the netatalk side of things. Since I'm replying to you in the a2server project (which is netatalk + samba), I'll describe that … in a separate comment so your eyes don't bleed.

@mgederberg
Copy link
Author

Right on Joseph... Yeah, I got the Wheezy image to run on my raspberry pi 2B+ here but for the life of me I cannot figure out what the heck is going on with ADTPRO and the serial ports that I have tried with the Pi and then it came to me, what if this build was intended for use with the pi card directly connected to the GPIO's? Is that what's happening here? I wanted to test drive it all before committing to purchase the card from Henry at ReactiveMicro so I have a null cable, my super serial card and then I tried a USB serial, a double serial hat to the GPIO and then a GPIO serial dongle too. No comm ports in ADTPRO for any of them. I know I have communications when I tested with a windows machine and the USB serial with ADTPRO.

@knghtbrd
Copy link
Member

The challenges to building a new a2server (as a Linux distribution for the Pi:

  • Custom Raspberry Pi OS (I'm just going to keep calling this Raspbian, sorry.)
  • Case sensitive filesystem problem
  • DDP kernel driver set up for macipgw usage
  • netatalk 2.2.5 is a disaster, security-wise, totally unsupported, etc.
  • samba
  • forks
  • macipgw
  • The EtherTalk bridge problem

A few of these are basically "solved problems", but I'm laying the issues out there so anyone who comes across this understands the pieces needed.

Custom distribution

This is done using a set of build scripts that I understand and have actually contributed to on the Pi. The RPF went kind of corporate on us a few years ago now and the whole thing is more isolated/closed off now … but I know how to do what we need to do. If everything else is done "the right way", this is easy.

Case-insensitive filesystem

At least one GS/OS version (Apple's IIRC) doesn't install right if you don't have this. For AppleTalk generally though, it's an optional thing for convenience. Still, we used to have a solution found/suggested by me and implemented by Ivan while he was still involved. It's no longer needed in Bullseye. Just create a directory (it has to be empty), chattr +F it, and anything you stick in there is case-insensitive but case-retentive like every non-UNIX OS seems to be. Hurray!

Android devices use a flash-friendly filesystem called F2FS. I find mention on Phoronix that it was slated to get casefold in 5.11, but bullseye ships with 5.10—if Raspbian switched to that for new installs (unlikely but possible), we'll need to revert that feature in the custom build.

DDP kernel driver for macipgw

There's a thing called dkms for wrangling kernel modules from outside the tree. I built a dkms package for the Linux kernel's DDP driver (AppleTalk's equivalent to TCP/IP) using the compile-time-only option we need to allow macipgw to work. It works. Is it done properly? No idea. Need someone who understands this to check it. But it does work in that it builds the driver we need, and it will move an existing DDP driver out of the way if your kernel comes with one. (Debian kernels do, Raspbian kernels I think do not.)

Problem: If you load the wrong DDP module before ours gets installed, you really need to reboot to get the correct driver loaded or macipgw will do nothing for you. Only really a problem for people running whatever a2server installer we have on existing Raspbian and Debian installations.

Netatalk 2.2.5 needs to go away already

a2server previously used netatalk 2.2.5 because something something better than 2.2.6. Nobody has ever actually explained how, except maybe that a default or two we change anyway is different on 2.2.6. Of course 2.2.6 was the last netatalk 2 version in Debian, it was removed. The packaging on it kinda needs redoing and the package is a little complicated. But I basically know how to package things for Debian still, so it'll take a bit of doing, mostly to catch up on current practices.

There isn't a 2.2.7, but there are security patches to 2.2.6. More might be needed, see below in the discussion about forks for what a solution might look like.

samba

Installing samba is easy. This provides modern filesharing of your AppleTalk share to Windows/Mac computers. Two issues exist with samba. The one I'll bring up here is that samba has a monolithic config file without a standard include directory. Files you can include! So if the requisite line doesn't already exist in your smb.conf, we can append the following:

# DO NOT REMOVE the following line! It's needed for a2server
    include = etc/smb/a2server.conf

If it's there at removal time, we can remove those lines. Removal should be done carefully though. If the comment and include line are there, like that, they can be removed. Up to two blank lines before them too. But if the comment and include line are not both there as we wrote them, we should only comment the line. Or are missing files simply ignored? Must investigate, they might be.

Forks and the proper way to do them

Prior to OS X, there was no standard way to represent forked files on a filesystem that didn't support them. The proper way after that was for file.ext, create ._file.ext for the resource fork. In zip files there was a MACOSX folder containing the resource forks that Apple's archive handler knew how to handle. Netatalk has had a few ways of doing this and none of them match the current way Apple and samba work. Netatalk 3 can do this the way samba does, but fixing this fits into the "going beyond what a2server used to do" category. The code to do it in netatalk 3 could be backported, though.

The other option is to actually just use netatalk 3. Wait, what? Netatalk 3 has no support for DDP! It's "AppleTalk" without the AppleTalk! TCP/IP only! Yes, except ultimately the way netatalk 3 works over TCP/IP is to open a TCP socket and send the same stuff over it that would be sent over DDP. To the point that if you have a IIgs with TCP/IP, you can connect to a TCP-based AppleTalk share, assuming it's been configured so you can authenticate with it! This solves most of the real security problems with netatalk 2 as well.

Of course the IIgs isn't going to always have a TCP/IP stack and the IIe isn't going to have it at all. It shouldn't be a major thing to write a bridge for netatalk 3 that allows you to run netatalk 2's atalkd and use that to talk to the more modern and somewhat simplified netatalk 3. It's possibly easier than trying to port features from netatalk 3 back to 2.2.6 + patches. It also means the netatalk people can retire their 2.x codebase (they already have, but I mean officially) while having vintage Mac and Apple II people not miss it. Maintaining atalkd and friends is a lot more reasonable without the afpd to worry about.

macipgw

It's not complex to compile this … I've just never really used it, so it's hard for me to test.

The Ethertalk bridge problem

As time passes, more and more of this stuff becomes rarer and rarer. Ethertalk bridges were never really common, but they are often buggy. I got a couple for $20 way back when, but you rarely see them even offered for sale anymore. And I can test the AsaneTalks I have, but that's about it.

LocalTalk out of your IIgs, vintage Mac, or IIe with a Workstation Card is serial. Yeah, 230.4kbps serial, but it's serial. I was last year years old when I realized that underneath all of the fancy cabling and adapters, the Zilog chip was really just doing some encapsulation and error checking in hardware, but otherwise these are just fast RS-232 serial ports, not using any of the fancy features beyond the physical link layer signaling protocol. Which we could do in software without a whole lot of fuss, probably.

This means it should totally be possible to implement a program that'd listen to the serial port, handle the SDLC packet layer, and pass the encapsulated DDP traffic on.

This is beyond my current technical abilities because I don't know these protocols and haven't got the setup I'd want to be able to snoop the serial traffic for testing/developing the interface. But wouldn't it be cool to be able to interface any LocalTalk device with your Pi using a quality USB-serial device and a PC to mac serial cable? Because that's what we're talking about here.

Wrapping up this novel (sorry)

Whew, that's a fair bit! But the pieces are there. The problems have solutions. The nice-to-haves can be planned for if they ever materialize, And really a fair bit of it involves just people testing hardware I don't have.

Things are similar on the a2cloud side: The distribution stuff is easy. I think I have sorted out how to handle which serial port does what, but it's a little complicated and needs testing. Previously we just put a getty on a serial port, but maybe it'd be cool if there was a modem emulator in there for local logins vs. telnet/telnet-ssl/ssh BBS access? (This might already exist to a large degree.) Shell tools are easy, save for email and email's only hard if you let it become hard.

The ADTPro/disk server stuff is a little complex because Dave Schmidt has AFAICT no interest in supporting Linux for it. Little enough for Mac, actually. I did manage to sort of start work on a Python ADTPro server, but I ran into some emulator bugs related to serial that slowed down my development Need to fix some hardware for working on that more and it's just been a lower priority due to the seemingly small level of interest given the many alternatives these days.

It's all doable if there's folks to do it for.

@mgederberg
Copy link
Author

Oh yeah, there's plenty of folks to do it for in the Apple //e, IIGS and even the the Mac 68K communities Joseph. With all that you've put out there, my feeling is the best course of action would be to get the distro running flawlessly on the STABLE Legacy version of Buster and go from there. Like I said, I have the Wheezy version running but it doesn't like to use the serial to super serial set up out of the gate, I think it was built specifically for the pi card because it kivetchs about the original configuration of the serial port not being there. Provided all the packages are updated to run with a stable and more robustly patched Buster, the VNC server works cool with it all and one can work easily to modify the serial connections in use for the pi with ADTPRO, it would be a winner across the community as a start. Does this make sense?

@mgederberg
Copy link
Author

Hey Joseph... Check this out?

https://youtu.be/IE5MOajykL0

@knghtbrd
Copy link
Member

These days, working on buster's like working on windows 8. Technically it's getting security patches but the only people using it are the people who haven't upgraded. It won't even run on new hardware because the device drivers aren't there. The stuff that works also works on bullseye, and the stuff that doesn't work on bullseye yet didn't work on buster either. If I am smart, I'd be making stuff work on Raspbian bullseye (since that's current) and Debian bookworm/sid, since that future-proofs things.

Quite conveniently, what have I got here but a Debian bookworm/sid machine and a Pi 4 with bullseye on it. I just need to build a custom version of that if I want a smaller download. I don't have the current version of the scripts installed for doing it, but that's a git pull away and can be done whenever I'm ready.

The biggest pain in the rear right now is going to be ADTPro. I'm not immediately in a position to test that right this minute without emulators that work due to vintage keyboard issues. Need to repair one or test on emulator. If I can get ADTPro to connect with applewin on my laptop, packaging ADTPro will be pretty easy since it no longer uses the dreaded rxtx library we had so much trouble with before.

Actually, if applewin works on my laptop, I can resume the thing I was doing earlier this year—I started a proof of concept Python ADTPro server. When I say that would make things 10,000,000 times easier, I'm not joking, because we can literally forego setting up a GUI for anything on the Pi. We just won't need it!

Do you have a way to connect your Pi to your Apple II using a super serial card right now? Even better if you have two such things so I can whip up a test of the "find the right serial port" stuff in RasppleII/a2cloud#27. I'm almost positive that works as suggested, but nobody else was willing to try it on a random setup I hadn't set up so that it absolutely would work. 😅

Step 1, set up serial ports. Step 2, set up ADTPro on one of them. Step 3, set up a terminal.

Curious, what model of Pi are you using?

@mgederberg
Copy link
Author

mgederberg commented Aug 21, 2022

I have two raspberry pi 2b+’s for this project. I do have some 3’s and 4’s too but having chatted with Ivan before I knew the system requirement for the old build was the 2b+. What with the price of pi’s these days it was cheaper to source used 2b+’s that met the system requirements. I also have two //e’s with super serial cards and floppy emu’s for testing. Shortly I will also have a pi card for the //e from reactive micro.

@knghtbrd
Copy link
Member

2B+ should work! It's the Zero 2 (which I haven't got) that I'd be concerned about.

@knghtbrd
Copy link
Member

See #64 for a current look at this stuff. Anything with ✦ or ✦✦ is pretty easy to do. ✦✦✦ stuff is going to take a little more effort for a number of reasons.

The GS/OS installer … technically it's kind of like ✦✦ or so because the script to do it pretty much exists and pretty much works. We just need a couple dependencies and it'd be ready to go! But it's ✦✦✦✦✦ because there is/was some dumb feud going on where a bunch of people don't want another person to have the ability to insert himself into (and control and probably monetize) it, and so they've taken the take their ball and going home attitude and … ugh.

@mgederberg
Copy link
Author

There's more than one way to skin a cat Joseph... Email me directly at [email protected]. Issues shared are issues split in half...

@IvanExpert
Copy link
Contributor

IvanExpert commented Aug 21, 2022 via email

@mgederberg
Copy link
Author

That's awesome news Ivan! I will certainly be testing it with my pi 2B+ and the pi card that Henry from ReactiveMicro has for me. Was the wheezy build intended for use with that card? Is this why I cannot seem to figure out the serial port configuration issues with the various other serial connections I'd tried with the pi?

@knghtbrd
Copy link
Member

knghtbrd commented Aug 22, 2022

Dug up last night the correct way to create a system user in a Debian postinst:

case "$1" in
    configure)
        adduser --system --quiet --disabled-password --gecos "a2server share owner" \
                --no-create-home --home /srv/a2server --group a2server
    ;;
esac

It might be necessary to do that in preinst, though. If it's done in preinst, it meas the user is guaranteed to exist before the postinst of any package that depends on the package that creates it. Nothing on my system does it that way, but the option exists. (Obviously, you do it on install instead of configure…) The things that populate directories with Apple II goodies otherwise need to pre-depend on the package that creates the user and directory, since those things need to exist with proper ownership.

Oh, casefold … ext4 has had it since Linux 5.2, so definitely not before bullseye. However the way to test for it is to see if the file /sys/fs/ext4/features/casefold exists and if it does, does it contain the string "supported". If not, ProDOS and netatalk are both dumb. That's why we used ciopfs before. For the time being we can detect this and stop on an error explaining what's wrong under the get it working principle … but ciopfs still exists, is packaged for Ubuntu, and I did update the package at some point to the latest upstream release so I could implement that as a fallback if needed.

If casefold is supported, logic looks like…

if dir does not exist:
    create dir
    try to chattr +F it
    if error:
        fail here

if dir hasn't got +F:
    create a new dir
    move file contents to it
    chattr +F the empty dir
    if error:
        put files back
        fail here
    put files back

Room to refactor that is obvious, but I didn't do it here because premature optimization leads to bugs. Musical chairs with files is required because directories have to be empty or chattr +F will fail. Also, if the files are moved and chattr does fail, you're well-positioned to modify the error condition to attempt to fall back to ciopfs later on.

Also, have a penguin.

a2server with penguin

(edit to improve adduser command)

@mgederberg
Copy link
Author

And I figured out that I have been trying to connect with a bad super serial card and that ADTPRO is now updated with RXTX being replaced now for JSSC. Gonna retest everything again shortly here...

https://www.youtube.com/watch?v=TzKumG1PcQo

@mgederberg
Copy link
Author

Here's the test on the pi... FAIL with serial connectivity, but not with Windows, why?

https://www.youtube.com/watch?v=Qgwjq_RziNk

@knghtbrd
Copy link
Member

It's possible that the JSSC that comes with ADTPro doesn't work, doesn't support the Pi, or was never tested. However, jssc does work, is used on the Pi often (it's how the Arduino development suite uploads programs, so it gets regular use), and if ADTPro isn't using it getting it to work may be as simple as removing the jssc that comes with ADTPro and making sure Raspbian's version is installed:

sudo apt update
sudo apt install libjssc-java

@mgederberg
Copy link
Author

mgederberg commented Aug 23, 2022

Gonna try that then Joseph... This is what happened with rxtx and the build as it sits in Wheezy (I tried to update rxtx, I couldn't so I uninstalled and then tried to reinstall and it could not "find" it, ahhh wheezy I love you!)

I thought I got it:
pi@raspberrypi ~ $ sudo apt-get install librxtx-java -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
librxtx-java is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.
So then I:
pi@raspberrypi ~ $ sudo apt-get remove librxtx-java -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
librxtx-java
0 upgraded, 0 newly installed, 1 to remove and 14 not upgraded.
After this operation, 911 kB disk space will be freed.
Do you want to continue [Y/n]? Y
(Reading database ... 78719 files and directories currently installed.)
Removing librxtx-java ...
AND THEN THIS HAPPENED:
pi@raspberrypi ~ $ sudo apt-get install librxtx-java -f
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
librxtx-java
0 upgraded, 1 newly installed, 0 to remove and 14 not upgraded.
Need to get 182 kB of archives.
After this operation, 911 kB of additional disk space will be used.
Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main librxtx-java armhf 2.2pre2-11
404 Not Found
Failed to fetch http://mirrordirector.raspbian.org/.../librxtx-java_2... 404 Not Found
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
pi@raspberrypi ~ $ sudo apt-get install librxtx-java --fix-missing
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
librxtx-java
0 upgraded, 1 newly installed, 0 to remove and 14 not upgraded.
Need to get 182 kB of archives.
After this operation, 911 kB of additional disk space will be used.
Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main librxtx-java armhf 2.2pre2-11
404 Not Found
Failed to fetch http://mirrordirector.raspbian.org/.../librxtx-java_2... 404 Not Found
E: Internal Error, ordering was unable to handle the media swap
pi@raspberrypi ~ $ sudo apt-get install librxtx-java --fix-missing install
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package install
pi@raspberrypi ~ $ sudo reboot
So trying again after a reboot...

And so then I got the LATEST version of ADTPRO for the build, version 2.1.0 right? So I chmod +x'ed adtpro.sh and then tried to run it and it complains about not finding or loading the class for the executable... probably because wheezy is so old?

@IvanExpert
Copy link
Contributor

IvanExpert commented Aug 23, 2022 via email

@knghtbrd
Copy link
Member

shrug I can't support jesse or wheezy. These no longer actually exist outside of a snapshot build I've never been able to recreate.

I'm honestly kinda frustrated and a little salty—I'm sure that's coming through in my responses and I really haven't intended it to because it's not your doing. I've actually been trying to be positive about this because I've wanted to get back to working on this, I have learned some things that should make stuff easier, and I genuinely want to see this mess of repositories become a useful tool. As computers go, the Apple II is always going to be my first love.

There's a few problems:

  1. ADTPro. David Schmidt told me to take a hike when I approached him about it, both regarding bugs and features. That may not necessarily be that it's me who asked as he's pretty reluctant to deal with Mac issues either. But ultimately, if it didn't work under Linux, he made it clear that was my problem, not his. And it didn't at the time, so … 🤷‍♂️

  2. I got netatalk to netboot my IIgs once. The AppleTalk bits of GS/OS errored when I tried to use them, and I still don't know if that's "proper" behavior. (I think it is. When netbooted, AppleTalk isn't running through GS/OS so the hardware's unavailable to GS/OS. If that's right, it's not likely high on anyone's priority list to change that in 2022.) At the time, I couldn't get enough of GS/OS booted locally to figure out how to set up a normal, noot-netbooted AppleTalk network.

  3. I know actually nothing about Marinetti or MacIP or macipgw. I've just never used any of it. I do have an Uthernet II card around here, but my keyboard bit it and since then I just haven't been able to do anything with that. And that's an issue for MacIP in general.

  4. I … don't have a working hardware Apple II right now. Three machines, all in need of a working keyboard. My IIgs would be the easiest to correct that with a cheap Mac keyboard or a Wombat if Steve's got any right now. I was looking earlier tonight, but that's not the biggest barrier right now.

  5. Back in I think 2018 or so, I had some illusions about the community kind of shattered. I got into a disagreement about something or other technical-wise with someone and they came right out and said it: "But you're not an Apple II developer, and as far as I'm concerned, you never will be." This isn't the view of a single person, apparently. It's a big club and I ain't in it. Or rather, it's a pretty small club, and a larger group of people who adore or abhor anyone they do. If one finds disfavor with certain folks, there's a bit of a glass ceiling to their involvement and participation in this "community". We all grew up as nerds, most of us on the receiving end of that kind of thing. Who'd have thought we'd willingly recreate it as adults?

    I must qualify that, because there are genuinely a significant number of people who don't play these sorts of games. And they've told me not to let it get to me, just keep doing my thing, etc. But it's not very likely anyone's going to stick their neck out too far for me. Doing so for someone else was my first mistake. I've made others.

When it comes right down to it, that last problem is the real problem. I stopped really trying to work on this stuff actively when I was effectively told I wouldn't be permitted beyond this glass ceiling I'd hit. There was stuff I simply didn't know how to do that was necessary to finish what I'd started, and it was pretty clear anybody who knew how it worked was unwilling to take the time to explain it to an outsider. I always said I'd come back to it when I'd learned what I needed or at least when there was someone who cared about the result.

I have learned quite a bit, actually. More than half of it just this year, almost without trying:

  • the workings of udev rules
    How matching is done, conditionals, tests, and how to modify what udev will do from an external script. Need that stuff for ADTPro and the serial terminal.

  • creating a 7-bit ASCII locale, setting the correct terminal for a getty
    The old distribution used an 8-bit locale that only broke a little for non-ASCII chars (but did break!), and changed the terminal so you didn't get colors/proper formatting when logged in via the console. This was not great for the serial terminal or the (unused by many) Linux console experience. I know how to fix both now.

  • systemd units
    Overriding all or part, conditionally, dependencies, making things start in the right order, this depends on that, but only if it's installed, that kind of thing. Needed for serial terminal, ADTPro, and half a dozen times in netatalk.

  • snooping serial connections
    One side or both sides, separately or combined. This will help with debugging.

  • GS/OS can use netatalk3
    I don't know how to set this up (it uses Marinetti and whatnot) but I was always told netatalk3 changed data structures so older clients wouldn't work. No, it's just the protocol, and people have gotten GS/OS to connect to AFP over TCP/IP.

  • Writing a DDP (AppleTalk) server doesn't have to be hard
    Timelord's an example of a really simple program. Y'know what else can be really simple. A program that listens for AFP connections on DDP and bridges them to connections to an AFP server on a TCP/IP socket. Forks working the same way on samba and netatalk. Vastly simpler afpd configuration.

  • LocalTalk isn't magic, it's just 230.4kbps serial
    All the magic needed to make LocalTalk work in the Zilog serial chip is encapsulating AppleTalk's network protocol over a link layer protocol called SDLC. We can do that in software using the same hardware you use for ADTPro on a IIgs. That's a down the road a ways thing, but removing hardware people can't easily get is a big part of making a2server relevant at a time when disk images are so easy to get to and from real hardware.

  • The Workstation Card isn't magic either
    This one's genuinely outside my programming skill for now. It's definitely outside my hardware skills. The Workstation Card is a ROM with several entrypoints for communicating with a black box that does magic. Mostly it hijacks MLI calls and redirects the ones that are network devices to be serviced by the black box. Who says that black box can't cost $4 and connect to the host via USB? Who says the host has to be AppleTalk if the black box bridges and emulates things?

Really cool things are possible for this project. But if it's my project, would any of them ever matter? I genuinely don't know. Seems what everyone really wants is Ivan to patch up his project. Mine was something else, and even if it's a good idea it'd probably be more welcome if I weren't a part of it.

@mgederberg
Copy link
Author

I gotcha Joseph... It is a big kids club and it can be very "political" so that's why one has to understand soft skills and positioning. Even the great Steve Jobs liked to "think" some of his ideas were his own, yet they were merely seeds someone else planted there. Ya gotta regular email me at [email protected] man...

@knghtbrd
Copy link
Member

Because I know it exists: rdmark/Netatalk-2.x fixes most of the major security problems in netatalk 2.

@mgederberg
Copy link
Author

Joseph,

Have you tried the new microm8 emulator? I think you'd be impressed... I got it running on the rpi 2b even when I updated openGL.... Don't forget to email me [email protected] alright?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants