If it went down like it did at CMU, IT polarized into a camp that wanted to maintain the traditional stack and a camp that wanted to tear it down and replace it with contemporary cloud services. When the latter won, they wasted no time in salting the earth of the former's territory.

Disclaimer: I wasn't actually party to any of this, I heard it second hand, corrections welcome.

I feel like that is different though. In-fact, that transition increased innovation capability in my view as someone who wrote some of the largest reaching on-campus applications at CMU during my time there.

Andrew was pretty dated and virtually everyone I knew was already forwarding their emails through their Gmail anyways. Transitioning to Google Apps was basically cutting out the middle-man while adding on some interesting functionality.

1. Now everyone also had a better calendar system and file sharing with Google Drive within the CMU namespace. This meant that clubs, for example, could create Google Forms that were restricted to actual CMU students with CMU email addresses, and they could use that guarantee to do more interesting things like adding information from the Directory on top of those emails without having to ask for it (such as Major and School).

2. We also got a way to allow people to use their Andrew logins on any student-made website with simple OAuth2 that restricted to using the @andrew.cmu.edu emails on Google Accounts. Before this, apps like ScheduleMan and the StuGov apps (which I developed on when I was there) had to get special permission to use Shibboleth and there were a bunch of restrictions for having those certs including having to run on CMU infrastructure.

Now, any student can create applications with the same login guarantees of only being accessed by CMU students and allow for one-click login and registration (since most relevant information can be obtained by looking up their email in the Directory), vastly increasing the usability of these apps.

In my view, that transition was definitely a net-positive to the CMU ecosystem, in both usability and development.

So why did the latter win?

The non-CS departments weren't huge fans of Andrew when I was there. Instead of learning to use it, they would work around it. I suspect the tension eventually came to a boiling point.

Many years ago in a past life, I worked on the network security team at the University of Chicago. We had a similar policy (and they may still for all I know) of just being able to requisition publicly routable IPs and run whatever you wanted on them with no default firewall rules applied at the border. Not for nothing did we call this a "target rich environment".

For all of the cool things I got to do (troubleshoot a breakin at the South Pole, send the RIAA a DMCA takedown notice when they stole our content (absolutely the highlight of my career), etc.), we spent the vast majority of our time on nonsense. We processed dumb breakins by the hundreds, had to enforce DMCA takedowns, and the like.

I'm also all for innovation and giving people the freedom to deploy services and innovate, but I would have killed to deploy all IPs by default behind NAT/firewalls and work with researchers to help them understand their responsibilities before giving them public IPs.

> behind NAT/firewalls

These are two separate things.

There is no security difference between "route port 80 of one of our public IPs through to my NATted address" and "open port 80 for my public address".

The public addresses are easier to administrate, troubleshoot, log, etc.

I agree. I meant the / to indicate that either one or a combination would have been helpful in different ways, but I certainly could have phrased it better.

Good question indeed. Why didn't MIT give more time to move, and in fact gave absolutely no notice, such that WMBR, the campus radio station, had to scramble to get their online radio back online again?

Just reading the story now, but I can confirm that college radio stations (and in general radio stations) are build to run and then be forgotten. My campus still uses a rather old copy of Simian which relies not only on IPv4, but filepaths shorter than 255 characters.

SIPB (MIT's volunteer student computing group) offers free "cloud hosting" to anyone with an Athena account.

http://xvm.mit.edu/

Honestly that sounds like a better alternative, than hosting on bare metal.

By default the service max out at 512 MB of RAM (yes, the service was invented in a different decade, way before AWS was cool). So if I want anything more than that, I'm better off running my own server.

Also ironically, I can't reach any of the newly NAT'd networks from my XVM instance. I bet the XVM maintainers haven't been warned about the NAT.

Did not know that. Honestly MIT's IT department should of given stakeholders more notice about this. I've honestly never had the chance to work on a public facing network (My alma mater, GMU, has a mostly natted network).

Isn't innovation worth more than the cost of malware, spam, and DMCAs?

Edit: In the late 80s the morris worm was launched from MIT, but the network admins of the 80s didn't overreact like this. I wonder why.

MIT is run by corporate shills now driven by profits, and IS&T is just another bureaucracy with its own interests to justify existence.

Did CIDR even exist in the 1980s, let alone NAT? (They are basically now selling off half of their "Class A" block now to AWS)

Cloud credits aren't a replacement for local servers.

Things I got to try at MIT that would be a lot harder on AWS:

- set up a TOR exit node

- set up a single-system image cluster across five 1U servers

- set up a ZFS box with RAID-Z and dm-crypt

- played with a real lisp machine

- put a raspberry pi on the internet (something I did for several projects)

But it still just doesn't make any sense to me. They can just firewall the entire campus network, and firewalling can very well be done without NAT...

At a certain level of firewalling you bring the disadvantages of NAT. For example, if you block all input, or even just HTTP(S).