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

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.

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

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

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.

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.

Others are pointing out that you cannot understand everything - and that's true enough.

But you only need to understand what's important. The experience of a good expert helps you to find that out.

As a systems administrator the recent AWS outage in the Middle East is the best recent example. There will be roughly three types of companies, separated by their understanding:

- Don't Understand - these companies thought that the cloud would handle this kind of thing for them, and are probably going to be doing a lot of finger-pointing in the near future.

- Do Understand, Don't Care - these companies did understand that high availability meant going multi-region, but decided against it for whatever reason. Probably cost vs perceived likelihood. These companies know that they've made a mistake. Short term they're wondering how to survive it, long term they'll be re-assessing their risk acceptance. Many may decide to stay single-region, but at least understand why.

- Do Understand, Do Care - these companies will simply be checking that their procedures worked for any manual parts of their failover, plus possibly looking at any improvements they can make given the real-life experience they've gained.

An LLM is just going to tell you how to implement it. It's not going to be thinking "what sort of availability do we require?", it may never start that conversation unless explicitly prompted. And even then it's going to return consensus opinions, which may not be what you want when evaluating risk.

I'd love to think a lot of companies will be looking at this event and updating their own risk register or justifying their existing risk decisions for hosting. But let's be honest - most won't even have thought about it, and won't until it goes wrong.

I'm honestly not sure I had a machine with more than 2 fixed disks until well into the days of Windows 7 and SATA. The exception would be logical disks such as Stacker or similar compressed volumes - but I wasn't using them until later either.

If I recall correctly before SATA we had IDE which only had two devices (primary & secondary) per controller, and usually only two controllers on a motherboard. Given the physical size of disks even you'd probably just have a boot disk, maybe a data disk and then perhaps two optical drives. So it's absolutely believable that nobody found the bug simply because nobody had a machine configured that way.

Sure, you could have SCSI for more disks. But if you did, then you were probably doing something that required a lot of CPU grunt - at which point you might just leave the PC behind and go to a UNIX workstation anyway.

OK, now I'm starting to get flashbacks to just how bad SCSI support was on the PC, and it's stripping the the rose-tint from my glasses. Time to go!