←back to thread

358 points ofalkaed | 1 comments | | HN request time: 0s | source

Just curious and who knows, maybe someone will adopt it or develop something new based on its ideas.
Show context
Animats ◴[] 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 #
JimDabell ◴[] No.45556101[source]
> - 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?

Amen. Postel’s Law was wrong:

https://datatracker.ietf.org/doc/html/rfc9413

We stop at the first sign of trouble for almost every other format, we do not need lax parsing for HTML. This has caused a multitude of security vulnerabilities and only makes it more difficult for pretty much everybody.

The attitude towards HTML5 parsing seemed to grow out of this weird contrarianism that everybody who wanted to do better than whatever Internet Explorer did had their head in the clouds and that the role of a standard was just to write down all the bugs.

replies(2): >>45556740 #>>45557342 #
maratc ◴[] No.45557342[source]
Just to remind you that <bold> <italic> text </bold> </italic> [0] that has been working for ages in every browser ever, is NOT a valid XHTML, and should be rejected by GP's proposal.

I, for one, is kinda happy that XHTML is dead.

[0]: By <bold> I mean <b> and by <italic> I mean <i>, and the reason it's not valid HTML is that the order of closing is not reverse of the order of opening as it should properly be.

replies(2): >>45557354 #>>45557442 #
reactordev ◴[] No.45557442[source]
It’s totally valid XHTML, just not recognized.

XHTML allows you to use XML and <bold> <italic> are just XML nodes with no schema. The correct form has been and will always be <b> and <i>. Since the beginning.

replies(2): >>45557501 #>>45557968 #
yoz-y ◴[] No.45557501[source]
The problem there is the order of tags not their names.
replies(1): >>45558284 #
reactordev ◴[] No.45558284[source]
Ooooo… now we’re talking. Sloppy HTML that closes a tag out of order or just declared out of order? Or rendering bugs when bold is before italic? It’s why XHTML should have been standard. Just dump, error out, make the developer fix it.
replies(1): >>45561371 #
simonask ◴[] No.45561371[source]
But the problem here is that our nice programmer-brained mental model does not match the actual requirements of text.

Unless you know about tree structures, it doesn’t make sense to the average person why you would have to stop and then restart a span of formatting options just because an unrelated attribute changed.

And that’s why XHTML failed - HTML is human-writable.

replies(2): >>45563064 #>>45564903 #
reactordev ◴[] No.45563064[source]
That’s not what the H stands for though… but I get what you’re saying. Because they opened in order, closing in same defined order should be allowed and thus we have all that peeking code to check to see if the next tag is that so we don’t error out and now we no longer conform to XHTML. Because non-engineers are writing HTML. It’s like putting the tires on before the brakes, but brakes after, and expecting it to work.

However because you can be both bold and italic, these should just be flags and that’s how they are now which is why b or i can be closed before b or i. I doubt they are just flags in the code of the browsers though because tags support styles and stuff.

replies(1): >>45570858 #
1. simonask ◴[] No.45570858{3}[source]
The larger point is what the T stands for: Text.

Tree structures just aren’t very user-friendly representations of text, and it’s supposed to be “hypertext” after all. :-)