As far as I know yes. From personal experience you can just `cd ..` your way out to the top parent directory and see all the orgs which use the system. I could see MIT and JPL(?) users from my cmu account and you can view the other users for each org (at least for MIT and for some of the other unis, I could never get the JPL stuff to load.) You can view the usernames and their public folder but nothing else.
There's also a lot of content from previous CMU classes. It was interesting to stumble upon some older 15151 course material which used some programming to prove certain theorems. They don't do this anymore (I'm not sure they even did this in the first place) and I'm assuming even for CMU CS students, expecting them to be able to programmatically prove theorems in a freshman class is a bit much. Cool stuff to root around in.
I only used it once, but you could almost see an alternate, different web. something that might have been if a different butterfly flapped it's wings. instead of HTML over HTTP we might of had HTML over AFS.
Another interesting almost was is ipsec vs SSL. I think in that case ipsec was it's own worst enemy. It has too many config options and is nearly unusable because of it.
AFS solved the cross OS permission problem by throwing away OS permissions and handling permissions itself entirely. It's tightly integrated with kerberos for auth/encryption enabling trivial federation.
It also solved a lot of data locality/ discovery issues by using SRV records. You want to visit /afs/cmu.edu? No problem, client looks up the dns record then uses that to ask the volserver where the volume actually lives.
The openafs server implementation is single threaded unfortunately. However is a more performant proprietary implementation via auristor (it's not all bad as Jeff Altman has been involved in openafs for a long time).
If you don't want to install the openafs kernel module on all your clients, there is also a stripped down in-kernel Linux client, kafs.
You still run into it in the research/edu space although a lot of places now block outbound afs so you don't accidentally leak data.
I highly recommend checking out other software that came out of project Athena. It really was a special time in compute and had some really novel concepts.
Source: I've spent waaaay too much time dealing with AFS and kerberos.
5 comments
[ 0.23 ms ] story [ 31.9 ms ] threadLike, 80% of desktop and mobile application features could be implemented with SyncThing as the backend.
There's also a lot of content from previous CMU classes. It was interesting to stumble upon some older 15151 course material which used some programming to prove certain theorems. They don't do this anymore (I'm not sure they even did this in the first place) and I'm assuming even for CMU CS students, expecting them to be able to programmatically prove theorems in a freshman class is a bit much. Cool stuff to root around in.
Another interesting almost was is ipsec vs SSL. I think in that case ipsec was it's own worst enemy. It has too many config options and is nearly unusable because of it.
It also solved a lot of data locality/ discovery issues by using SRV records. You want to visit /afs/cmu.edu? No problem, client looks up the dns record then uses that to ask the volserver where the volume actually lives.
The openafs server implementation is single threaded unfortunately. However is a more performant proprietary implementation via auristor (it's not all bad as Jeff Altman has been involved in openafs for a long time).
If you don't want to install the openafs kernel module on all your clients, there is also a stripped down in-kernel Linux client, kafs.
You still run into it in the research/edu space although a lot of places now block outbound afs so you don't accidentally leak data.
I highly recommend checking out other software that came out of project Athena. It really was a special time in compute and had some really novel concepts.
Source: I've spent waaaay too much time dealing with AFS and kerberos.