Most active commenters
  • troupo(6)

←back to thread

Ask HN: Abandoned/dead projects you think died before their time and why?

358 points ofalkaed | 22 comments | 11 Oct 25 22:16 UTC | HN request time: 2.36s | source | bottom

Just curious and who knows, maybe someone will adopt it or develop something new based on its ideas.
Show context
Animats ◴[12 Oct 25 07:24 UTC] No.45556053[source]▶
- Photon, the graphical interface for QNX. Oriented more towards real time (widgets included gauges) but good enough to support two different web browsers. No delays. This was a real time operating system.

- MacOS 8. Not the Linux thing, but Copeland. This was a modernized version of the original MacOS, continuing the tradition of no command line. Not having a command line forces everyone to get their act together about how to install and configure things. Probably would have eased the tradition to mobile. A version was actually shipped to developers, but it had to be covered up to justify the bailout of Next by Apple to get Steve Jobs.

- Transaction processing operating systems. The first one was IBM's Customer Information Control System. A transaction processor is a kind of OS where everything is like a CGI program - load program, do something, exit program. Unix and Linux are, underneath, terminal oriented time sharing systems.

- IBM MicroChannel. Early minicomputer and microcomputer designers thought "bus", where peripherals can talk to memory and peripherals look like memory to the CPU. Mainframes, though, had "channels", simple processors which connected peripherals to the CPU. Channels could run simple channel programs, and managed device access to memory. IBM tried to introduce that with the PS2, but they made it proprietary and that failed in the marketplace. Today, everything has something like channels, but they're not a unified interface concept that simplifies the OS.

- CPUs that really hypervise properly. That is, virtual execution environments look just like real ones. IBM did that in VM, and it worked well because channels are a good abstraction for both a real machine and a VM. Storing into device registers to make things happen is not. x86 has added several layers below the "real machine" layer, and they're all hacks.

- The Motorola 680x0 series. Should have been the foundation of the microcomputer era, but it took way too long to get the MMU out the door. The original 68000 came out in 1978, but then Motorola fell behind.

- Modula. Modula 2 and 3 were reasonably good languages. Oberon was a flop. DEC was into Modula, but Modula went down with DEC.

- XHTML. Have you ever read the parsing rules for HTML 5, where the semantics for bad HTML were formalized? Browsers should just punt at the first error, display an error message, and render the rest of the page in Times Roman. Would it kill people to have to close their tags properly?

- Word Lens. Look at the world through your phone, and text is translated, standalone, on the device. No Internet connection required. Killed by Google in favor of hosted Google Translate.

replies(21): >>45556101 #>>45556208 #>>45556229 #>>45556271 #>>45556669 #>>45556854 #>>45556998 #>>45557079 #>>45557129 #>>45557453 #>>45557719 #>>45557765 #>>45558292 #>>45558373 #>>45558638 #>>45558754 #>>45559205 #>>45560537 #>>45561793 #>>45565845 #>>45582965 #
1. PaulRobinson ◴[12 Oct 25 07:52 UTC] No.45556208[source]▶
Nice list. Some thoughts:

- I think without the move to NeXT, even if Jobs had come back to Apple, they would never have been able to get to the iPhone. iOS was - and still is - a unix-like OS, using unix-like philosophy, and I think that philosophy allowed them to build something game-changing compared to the SOTA in mobile OS technology at the time. So much so, Android follows suit. It doesn't have a command line, and installation is fine, so I'm not sure your line of reasoning holds strongly. One thing I think you might be hinting at though that is a missed trick: macOS today could learn a little from the way iOS and iPadOS is forced to do things and centralise configuration in a single place.

- I think transaction processing operating systems have been reinvented today as "serverless". The load/execute/quit cycle you describe is how you build in AWS Lambdas, GCP Cloud Run Functions or Azure Functions.

- Most of your other ideas (with an exception, see below), died either because of people trying to grab money rather than build cool tech, and arguably the free market decided to vote with its feet - I do wonder when we might next get a major change in hardware architectures again though, it does feel like we've now got "x86" and "ARM" and that's that for the next generation.

- XHTML died because it was too hard for people to get stuff done. The forgiving nature of the HTML specs is a feature, not a bug. We shouldn't expect people to be experts at reading specs to publish on the web, nor should it need special software that gatekeeps the web. It needs to be scrappy, and messy and evolutionary, because it is a technology that serves people - we don't want people to serve the technology.

replies(5): >>45556831 #>>45557240 #>>45558176 #>>45558209 #>>45565860 #
2. donatj ◴[12 Oct 25 09:41 UTC] No.45556831[source]▶
On XHTML, I think there was room for both HTML and a proper XHTML that barks on errors. If you're a human typing HTML or using a language where you build your HTML by concatenation like early PHP, sure it makes sense to allow loosey goosey HTML but if you're using any sort of simple DOM builder which should preclude you from the possibility of outputting invalid HTML, strict XHTML makes a lot more sense.

Honestly I'm disappointed the promised XHTML5 never materialized along side HTML5. I guess it just lost steam.

replies(2): >>45557166 #>>45557173 #
3. detaro ◴[12 Oct 25 10:49 UTC] No.45557166[source]▶
But a HTML5 parser will obviously parse "strict" HTML5 just fine too, what value is there to special-case the "this was generated by a DOM builder" path client-side?
4. chrismorgan ◴[12 Oct 25 10:51 UTC] No.45557173[source]▶
> Honestly I'm disappointed the promised XHTML5 never materialized along side HTML5. I guess it just lost steam.

The HTML Standard supports two syntaxes, HTML and XML. All browsers support XML syntax just fine—always have, and probably always will. Serve your file as application/xhtml+xml, and go ham.

replies(2): >>45560189 #>>45567453 #
5. JimDabell ◴[12 Oct 25 11:03 UTC] No.45557240[source]▶
> XHTML died because it was too hard for people to get stuff done.

This is not true. The reason it died was because Internet Explorer 6 didn’t support it, and that hung around for about a decade and a half. There was no way for XHTML to succeed given that situation.

The syntax errors that cause XHTML to stop parsing also cause JSX to stop parsing. If this kind of thing really were a problem, it would have killed React.

People can deal with strict syntax. They can manage it with JSX, they can manage it with JSON, they can manage it with JavaScript, they can manage it with every back-end language like Python, PHP, Ruby, etc. The idea that people see XHTML being parsed strictly and give up has never had any truth to it.

replies(1): >>45558470 #
6. bsimpson ◴[12 Oct 25 13:41 UTC] No.45558176[source]▶
Didn't Google already own Android when iOS was announced?
replies(1): >>45558478 #
7. eloisant ◴[12 Oct 25 13:48 UTC] No.45558209[source]▶
They would have gotten another modern OS instead of Next as the base for MacOSX (then iOS).

Another possibility they were exploring was buying BeOS, which would have been pretty interesting because it was an OS built from scratch in the 90's without any of the cruft from the 70's.

Also, the only thing specific to Next that survived in MacOSX and iOS was ObjectiveC and the whole NextStep APIs, which honestly I don't think it a great thing. It was pretty cool in the 90's but when the iPhone was released it was already kinda obsolete. For the kernel, Linux or FreeBSD would have worked just the same.

replies(1): >>45560187 #
8. troupo ◴[12 Oct 25 14:28 UTC] No.45558470[source]▶
> The syntax errors that cause XHTML to stop parsing also cause JSX to stop parsing. If this kind of thing really were a problem, it would have killed React.

JSX is processed during the build step, XHTML is processed at runtime, by the browser.

replies(2): >>45562025 #>>45564782 #
9. troupo ◴[12 Oct 25 14:29 UTC] No.45558478[source]▶
Yes, and they were going to position it against Windows Mobile.

When iOS was announced, Google scrambled to re-do the entire concept

replies(1): >>45559653 #
10. giobox ◴[12 Oct 25 16:51 UTC] No.45559653{3}[source]▶
Not so much Windows Mobile, which never achieved serious market share. It was originally more planned to be a Blackberry competitor, and the early Android handset prototype concepts were all blackberry knockoffs with similar physical keyboard layouts.

It has always appeared though like you suggest, that the project quickly pivoted to candy bar touch phones following the release of the original iPhone. It's worthwhile to remember that the industry wasn't nearly as convinced that touching glass was the future of mobile typing in 2007 as it later became, and the sales volume of Blackberrys back then was often incorrectly cited as evidence to support the case against touch.

> https://www.bgr.com/tech/iphone-vs-android-original-google-b...

replies(2): >>45560022 #>>45562546 #
11. troupo ◴[12 Oct 25 17:28 UTC] No.45560022{4}[source]▶
I clean forgot about Blackberry :)

Android team ended up delaying Android release by a year: https://appleinsider.com/articles/13/12/19/googles-reaction-...

12. otabdeveloper4 ◴[12 Oct 25 17:48 UTC] No.45560187[source]▶
> without any of the cruft from the 70's

By "cruft" you mean "lessons learned", right?

13. ◴[12 Oct 25 17:48 UTC] No.45560189{3}[source]▶
14. throw_await ◴[12 Oct 25 21:21 UTC] No.45562025{3}[source]▶
Invalid XHTML woild have been caught in the test suite
replies(1): >>45565461 #
15. nrdvana ◴[12 Oct 25 22:20 UTC] No.45562546{4}[source]▶
I still hate touch and would still buy a keyboard phone if anyone was making a good one
16. naasking ◴[13 Oct 25 04:53 UTC] No.45564782{3}[source]▶
Yes, which presumably would have actually been tested by someone before it was uploaded.
replies(1): >>45565462 #
17. troupo ◴[13 Oct 25 06:50 UTC] No.45565461{4}[source]▶
Neither you nor the sibling commentator can be serious.
18. troupo ◴[13 Oct 25 06:50 UTC] No.45565462{4}[source]▶
Neither you nor the sibling commentator can be serious.
replies(1): >>45567697 #
19. pjmlp ◴[13 Oct 25 07:52 UTC] No.45565860[source]▶
There is hardly any UNIX stuff for iOS and Android applications sold via the respective app stores.

You won't get far with POSIX on any of the platforms.

20. ttepasse ◴[13 Oct 25 12:09 UTC] No.45567453{3}[source]▶
There was even a polyglot (X)HTML 5 which I always found genius - there are many more XML parsers than HTML5 parsers in the world.

https://www.w3.org/TR/html-polyglot/

21. naasking ◴[13 Oct 25 12:39 UTC] No.45567697{5}[source]▶
Hey, guess what else is processed at runtime: all of the dynamically typed programming languages that run half of the internet. I wonder how they can still get reliability despite that?
replies(1): >>45571657 #
22. troupo ◴[13 Oct 25 18:21 UTC] No.45571657{6}[source]▶
1. They don't really

2. That is literally besides the point we're arguing here.

At this point i have no interest in this "discussion".

Adieu.