Lotus/IBM didn't ignore those standards.

The Notes directory was based on X.500 - it had the same attributes etc. Notes didn't implement DAP, but then almost nobody did, which is why we got LDAP.

There was an add-on connector for X.400 mail. I remember installing it a couple of times. It was fine, if cumbersome due to the nature of X.400. ;-)

They also didn't ignore SMTP. There was a connector for it for Notes 4.0 and 4.1, and starting with Notes 4.5 that connector was bundled in the box. Starting with Release 5 they retired the connector and moved SMTP functionality to be native in the mail router process, and for security they provided a separate SMTP listener task. Both of these were configured in the Notes Directory via Server Documents and Configuration Documents, just like any other feature of the server. If a Domino server wasn't sending or receiving SMTP, it's because its administrator didn't want it to, not because it couldn't.

It wasn't a walled garden, or if it was the wall was very low. By comparison Microsoft's first attempt to dethrone Notes - Exchange Public Folders - was a completely walled garden. And a very well fertilised one which people avoided due to the smell.

But it's OK, Microsoft then gave us SharePoint. The fact that Microsoft's customers rushed to it tells you how bad Public Folders were. So your comment "That and, you know, Microsoft" is much closer to the truth than protocol support.

(Source: I was a Principle Certified Lotus Domino Administrator for multiple versions, and have used & administered Lotus Notes versions from version 3.33 through to 8.5. I worked at a consultancy and installed many, many implementations of Lotus Notes across a number of topologies. I also had an Exchange Server MCP and worked with multiple versions of that too.)

I worked with Notes for 15 years, and your point C baffles me. Could you please elaborate?

I still remember the Notes/Domino Server TCP port number - 1352. I've used it so often in firewall configurations or communications with customers and firewall teams.

I had servers hosting data for replication to customers over the internet. (Including patent data, very sensitive in both security and timeliness). We never had any issues connecting servers over the internet. It was easy, reliable and simple.

It was also very secure due to the PKI infrastructure built into Notes, the ability to require encrypted network traffic, and the various layers of security on the server.

Plus the NRPC protocol has its own proxying feature, called "Passthru Servers". That allows clients or servers to connect to other servers via an intermediate server - and that intermediate can actually blacklist or whitelist other clients/servers from using it. It's all very easy to implement, a core part of the product that any Notes administrator should know about.

But what really confuses me is you talking about AD. You can do some integration with AD and Lotus Notes, but out of the box it uses its own directory and PKI infrastructure. That's famously one of the things people held against it - that it didn't use AD or NDS. If you did turn on the AD integration then I guess you'd need access to AD, but that's your decision - and the downsides of it are much the same for any local client software you're trying to authenticate via your AD.

I simply can't reconcile what you've said with my experience. So I'm very interested to understand what you're getting at there.

This. Microsoft was very aggressive in courting CIOs and senior management, and had a great sales team.

I remember hearing that they had a storage calculator spreadsheet that would allow you to calculate how many IOPS you'd need from your storage to deploy Exchange.

Everyone I knew working with Notes or other products was gobsmacked. Why would you need that? Just buy decent storage. Nobody outside of the Exchange world cared about IOPS, unless you were dealing with of high thousands of users on one machine/cluster.

But the Exchange Server storage layer was a total dog's breakfast. (And not a healthy dog, either.) So disk performance was much more important for them.

And that spreadsheet was like crack for the senior management layer. They suddenly got to play with the numbers of users, mails per hour, mailbox quotas - then feel like they had involvement. They had input. They could go to their storage vendors with those figures and speak authoratitively about their requirements.

Those vendors would humour them, and sell them the exact same array that everyone else was buying for that capacity requirement and budget.

But Microsoft had turned a weakness into a strength, by making the managers feel like they had real input into the process.

Honestly, that spreadsheet was a genius move that it took me years to understand.

I administered messaging and groupware systems for over 15 years. It was a large chunk of my career. I worked with both Exchange Server/Outlook and Lotus Domino/Notes, and generally preferred Lotus Domino - but both had their issues.

This article doesn't feel like it was written by someone who was using these platforms, nor like anyone was there at the time was consulted.

For example, focusing on F5 is odd. F5 is not the Office refresh key. F9 is. Excel uses it to recalculate. Word uses it to refresh fields. Outlook should have used it to fetch/refresh mail, but for some reason they went with the Windows/IE platform teams' choice of F5. Microsoft did actually switch back to using F9 in Outlook, and there was a significant outcry from their users. None of this is mentioned.

Similarly there's a screenshot of a messagebox stating that there are too many windows. No context given, but I'd bet it's from Loutus Notes 4.6 or earlier, which used MDI. MDI is limited to 9 windows. I hit that limit in a lot of applications back in the late WIndows 3.1/early Windows 95 days, at the peak of MDI. Notes Release 5 moved away from MDI, and gave the user a tabbed interface. The Exchange Mail and Outlook clients never used MDI, opening a new window for each mail - which may or may not be a better solution, given that Windows didn't have task stacking on the taskbar at the time. Nine tabs in Notes was just one taskbar entry, nine windows with Outlook was heading towards a serious usability problem...

I'd like to note that the Notes client didn't benefit from the network effects that Outlook did. At the time many of the complaints in the article were being made software packaging and deployment was in its infancy. Many environments made Notes and Outlook/Office part of their base build making updates a difficult thing to accomplish. Not to mention that the installers were quite large, taxing many networks of the time. But Outlook had the benefit of being part of Office - sometimes people wanted the latest features in Word or Excel, so the effort was made to update the installation. Notes had no such advantage. A similar network effect arrives when it comes to licensing, given that larger organisations will have volume licensing deals.

By contrast on the server side Exchange Server was a complete PITA to upgrade. You don't merely install new software, you build an entire new infrastructure and migrate mailboxes over to it. Very expensive, especially in the days of physical hardware. Whereas Lotus Notes Server/Domino was very easy to upgrade or extend.

As a result many Notes installations were up to date on their backend but not the frontend, whereas many Outlook installations were the other way around.

Anyway, I've gone on for too long - much like all the products we're discussing here. ;-)

Hiya. Sorry, but you might not like what I have to say - I still hope that you read it all though.

I doubt that this is the future. Maybe it is for a small number of people on HN, but outside of this site there's no way it's the future.

You're amazed by this because it's the ultimate expression of the luxury of focus. Unfortunately whilst developers and artists get the luxury of focus, most other people don't. Most other people have either responsibilities or duties that require them to be interruptable.

Being interrupted sucks. But for most people it's a fundamental part of their job. IT, HR, Finance, Security/Compliance, Facilities, and so many more. As an example for folks in sales not being interrupted may mean a lost sale. That's typically not acceptable.

So what you value from AVP is a detrimental thing for others.

Worse than that, AVP is a very expensive way of getting that focus. We could buy you a bigger monitor and some quality headphones for less than a quarter of the price.

Right now for five hundred bucks I can buy a 34" curved widescreen monitor with built in webcam, microphone and USB power delivery of 100 watts. Someone can plug their laptop into that and charge it whilst getting a webcam and microphone over that same cable. It's very cool. Throw in some noise cancelling headphones and the total bill is maybe seven hundred bucks.

That's the price target that AVP has to compete with. And it's a moving target - the cost of monitors and noise cancelling headphones will go down as well.

Let's be honest, right now I could buy a headphones/monitor combination for you both at an office desk AND at home, pay for the courier to your house, and still have a sizable chunk of change from the cost of AVP. If you scale this up over the whole of society, the costs of AVP vs a monitor/headphones combination are HUGE and yet the gains are, for most situations, marginal at best.

And I'm only talking about cost here. If IT departments have to start issuing AVP devices, they're going to need to do the fitting - something only Apple currently does. They'll have to keep records of the pads used for you. They'll have to keep records of your optician's prescription, and spares of the lenses issued to you (if needed). An AVP is a very personal device - if yours breaks, we can't just pick one of the shelf and know it will work for you immediately, the padding and lenses ensure that.

Imagine an office with 100 desks. Which is easier - 100 monitors like the ones I described before, or 100 AVP headsets? The monitors allow hotdesking if necessary, they work with any laptop (even visitors). They're fungible. Headphones are a bit more personal, but still fungible in a pinch. An AVP headset is the exact opposite of that.

Oh, and I've just realised that IT teams are going to need to either keep a record of your prescription for the lenses, or have delays in issuing replacements. That prescription is PII. Now we have a whole new legal problem to deal with.

None of these issues are insurmountable, but all of the solutions are extra cost. For an already costly device.

The future isn't AVP. The future is big monitors and headphones. Because that future is already here, and its logistics and costs are simple and manageable.

I really am sorry to be the one to tell you this. I know you value the luxury of focus. I hope that, if anything, this comment allows you to enjoy and appreciate that luxury more in the future.

Different products can target different segments of the market. The question is just whether this one is large enough to support something like the AVP

Absolutely. I was, if anything, trying to caution against assuming that the segment the poster was in was the whole of the market.

(Personally I think that the AVP market is too small for the modern Apple to care about, and I don't see similar products from competitors ever having the hype.)

Windows 1-3 ran on top of DOS, with a small caveat for Windows 3.x

Windows 3.x running in 386 Enhanced Mode had a very small multi-threaded preemptive kernel, which it used to handle its MS-DOS windows. So whilst each Windows program ran cooperatively within Windows and had no memory protection, Windows itself and each DOS window it opened were pre-emptively multitasked and had better memory protection. This wasn't very well documented, but it's the beginnings of Windows no longer running on top of DOS and instead taking over control of the machine.

Windows 3.1 also introduced "32 Bit Disk Access" which used a custom disk driver to bypass DOS and the BIOS and speed things up. Windows 3.11 (Windows for Workgroups) extended that to "32 Bit File Access", which bypassed DOS for file operations.

Windows 95 only used DOS as a bootstrapper. It would be completely incorrect to say that Windows 95 "ran on top of DOS", as once Windows 95 finished booting it had effectively pulled the rug out from DOS and was handling all I/O, memory operations, and so forth. It would be like saying that Linux runs on top of GRUB - GRUB is no longer in control of the machine, so it's just not true.

Not that I'm saying you were stating Windows 95 ran on top of DOS, you understand! I'm just putting this information here for educational reasons and expanding on your comment. ;-)

SMTP won because it was simpler, but it's probably good to look at why it was simpler.

SMTP handled routing by piggybacking on DNS. When an email arrives the SMTP server looks at the domain part of the address, does a query, and then attempts transfer it to the results of that query.

Very simple. And, it turns out, immensely scalable.

You don't need to maintain any routing information unless you're overriding DNS for some reason - perhaps an internal secure mail transfer method between companies that are close partners, or are in a merger process.

By contrast X.400 requires your mail infrastructure to have defined routes for other organisations. No route? No transfer.

I remember setting up X.400 connectors for both Lotus Notes/Domino and for Microsoft Exchange in the mid to late 90s, but I didn't do it very often - because SMTP took over incredibly quickly.

An X.400 infrastructure would gain new routes slowly and methodically. That was a barrier to expanding the use of email.

Often X.400 was just a temporary patch during a mail migration - you'd create an artificial split in the X.400 infrastructure between the two mail systems, with the old product on one side and the new target platform on the other. That would allow you to route mails within the same organisation whilst you were in the migration period. You got rid of that the very moment your last mailbox was moved, as it was often a fragile thing...

The only thing worse than X.400 for email was the "workgroup" level of mail servers like MS Mail/cc:Mail. If I recall correctly they could sometimes be set up so your email address was effectively a list of hops on the route. This was because there was no centralised infrastructure to speak of - every mail server was just its own little island. It might have connections to other mail servers, but there was no overarching directory or configuration infrastructure shared by all servers.

If that was the case then your email address would be "johnsmith @ hop1 @ hop2 @ hop3" on one mail server, but for someone on the mail server at hop1 your email address would be "johnsmith @ hop2 @ hop3", and so on. It was an absolute nightmare for big companies, and one of the many reasons that those products were killed off in favour of their bigger siblings.

> ... why it was simpler.

In the early 90s I implemented a gateway between Novell email and X.400. What amused me the most was X.400 specified an exclusive enumerated list of reasons why email couldn't be delivered, including "recipient is dead". At the X.400 protocol level this was a binary number. SMTP uses a 3 digit number for general category, followed by a free form line of text. Many other Internet standards including HTTP use the same pattern.

It was already obvious at the time that the X.400 field was insufficient, yet also impractical for mail administrators to ensure was complete and correct.

That was the underlying problem with the X.400 and similar where they covered everything in advance as part of the spec, while Internet standards were more pragmatic.

> so your email address was effectively a list of hops on the route

Who can forget addresses like "utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!rms@mit-prep"

I am still trying to forget setting up sendmail.cf in that era.

Ehhh.. This is a bit revisionist for a couple reasons.

1. smtp predates dns. or really even most of the internet. It was originally designed to work over uucp.

2. early smtp used bang paths (remember those) where the route or partial route is baked into the path.

A bit, perhaps, but not much.

At the time of bang paths, smtpd was just one of several email protocols in use. And X.400 was absolutely a competitor at the time.

A decade or two later, when it was clear that smtp had become the least common denominator between all email systems, then smtp absolutely used DNS and even had its own record type, MX.

So I don't think it is wrong to say a large part of why it won out on all other protocols was that you didn't have to mess with email routing once MX records was universally accepted.

Of course, for reliability, you could even bake multiple paths into the envelope address.

What I really liked about ZoneAlarm wasn't just that it was a very nice technology - and it was; but also that it got the user expectations and training right from a very early stage.

It was quite insistent on the fact that it would be "noisy" at first as it queried all the programs you ran, but would then quieten down once it had been "trained". It got that across in clear, simple language.

I think it was so successful because it got the soft side of its security job right as well as the hard part. It's certainly why I recommended it to anyone at the time...

Was working as an IT consultant. We got a call from an international manufacturer in the area for support. Local lead IT manager took down the firewall which infected their computer network around the world. All they wanted were bodies to help clean systems and apply OS updates.

My personal computer had ZoneAlarm on it. It became ground zero for reporting about infected systems. They ignored systems they thought were save; CISCO phone system running on Windows server and other backend devices. The company then bought a few licenses to run their own laptops.

It is such a same that Microsoft destroyed _ERD Commander_ and other quality tools which assisted in the clean up.

Yes and no.

Yes. The incentives for writing reliable, robust code were much higher. The internet existed so you could, in theory, get a patch out for people to download - but a sizeable part of any user base might have limited access, so would require something physical shipped to them (a floppy or CD). Making sure that your code worked and worked well at time of shipping was important. Large corporate customers were not going to appreciate having to distribute an update across their tens of thousands of machines.

No. The world wasn't as connected as it is today, which meant that the attack surface to reasonably consider was much smaller. A lot of the issues that we had back then were due to designs and implementations that assumed a closed system overall - but often allowed very open interoperability between components (programs or machines) within the system. For example, Outlook was automatable, so that it could be part of larger systems and send mail in an automated way. This makes sense within an individual organisation's "system", but isn't wise at a global level. Email worms ran rampant until Microsoft was forced to reduce that functionality via patches, which were costly for their customers to apply. It damaged their reputation considerably.

An extreme version of this was openness was SQL Slammer - a worm which attacked SQL Servers and development machines. Imagine that - enough organisations had their SQL Servers or developer machines directly accessible that an actual worm could thrive on a relational database system. Which is mindboggling to think about these days, but it really happened - see https://en.wikipedia.org/wiki/SQL_Slammer for details.

I wouldn't say that the evidence points to software being better in the way that we would think of "better" today. I'd say that the environment it had to exist in was simpler, and that the costs of shipping & updating were higher - so it made more sense to spend time creating robust software. Also nobody was thinking about the possible misuse or abuse of their software except in very limited ways. These days we have to protect against much more ingenious use & abuse of programs.

Furthermore today patching is quick and easy (by historical comparison), and a company might even be offering its own hosted solution, which makes the cost of patching very low for them. In such an environment it can seem more reasonable to focus on shipping features quickly over shipping robust code slowly. I'd argue that's a mistake, but a lot of software development managers disagree with me, and their pay packet often depends on that view, so they're not going to change their minds any time soon.

In a way this is best viewed as the third age of computing. The first was the mainframe age - centralised computer usage, with controlled access and oversight, so mistakes were costly but could be quickly recovered from. The second was the desktop PC age - distributed computer usage, with less access control, so mistakes were often less costly but recovering from them was potentially very expensive. The third is the cloud & device age, with a mix of centralised and distributed computer use, a mix of access control, and potentially much lower costs of recovery. In this third age if you make the wrong decisions on what to prioritise (robustness vs speed of shipping), it can be the worst of both the previous ages. But it doesn't have to be.

I hope that makes sense, and is a useful perspective for you.

Yo. Firstly, thanks for the trip down memory lane - well written, engaging, fun. My mind is still stuck in those days even after finishing the article, as you can tell from my anachronistic greeting.

Secondly, as someone who spent 15 years working with Lotus Notes, I can assure you that you can run it standalone. Obviously it makes no real sense for a Groupware product, but it can be done. To the Notes client opening a database locally or on a mail server is largely the same.

The main issue is that people used Notes to communicate and collaborate. So you could just go creating new Address Books, Discussion databases, Document Libraries and so on, but what exactly are you proving with that? It's be like just firing up the Microsoft Mail client and only looking at the address book...

Whilst I'm aware that there's plenty in Notes that people didn't like, I do think that there are some gems hidden in there which it would have been nice to have kept. The Notes dialect of Rich Text had a couple of niceties (programmable buttons, collapsible/expandable Sections). The database engine itself was unparalleled at the time, and in some ways it still hasn't been bettered.

But the issue remains that you'd need to set up a Notes/Domino Server (depending on your version - 4.5 onwards it's called Domino), and a small network. And that's a ball-ache that nobody wants. It can speak IPX/SPX and NetBIOS, so it doesn't have to be as complicated as TCP/IP, but it's still a lot of prep work before you even get to start looking at the usage. :-(

That having been said, I was a Principal Certified Lotus Professional on the Sysadmin track for about three versions of Notes, from 4.6 to 6, and can definitely help if you ever did want to do that. Feel free to email me at phil [at] philipstorry.net if you're ever so lacking in subjects that you feel forced into this last resort.