Hacker News Reader

Comment by pmelendez | Hacker News Reader

The only good thing (I think) of a generalist is that one is used to adapt, but yeah... it gets boring sometime. Although after a while, is interesting to see how we reinvent wheels and show them with a new fancy name, it is a pattern that you would see more or less each 10 years.

Sometimes it feels like everything was already invented in the 60's.

View on HN

> Sometimes it feels like everything was already invented in the 60's.

Reading up on the capabilities of early mainframes is eye-opening if you (like me) grew up on Pentiums.

Could you recommended an overview?

Yes, especially the MULTICS operating system was so advanced and dozens of decades ahead that we still borrow from its concepts. It had for example 16 security rings. Intel CPUs support only 4 CPU rings, and Windows e.g. uses only 2 rings (for kernel mode and user mode) (hypervisor mode uses another ring in recent iterations).

Initial software based Multics had 64 rings, and as I recall only 8 in the hardware versions. No more than 4 were needed in practice: 0 for root, 1 for mail (e.g. you could delete mail you'd sent to other people from their mailboxes if they'd not read it yet), 4 for normal users, and 5 for some stuff that e.g. allowed anyone to use, but was restricted at touching anything deeper in the system.

AMD dropped rings in their 64 bit architecture which Intel was forced to adopt, so they're becoming a historical curiosity.

> AMD dropped rings in their 64 bit architecture which Intel was forced to adopt, so they're becoming a historical curiosity.

Not quite. Hypervisors are operating in Ring -1, SMM is equivalent to another ring above that, and I can't find anything about AMD64 dropping Ring 1/2? Ring 0/3 at least are still in use.

I submit that "supervisor/user" isn't an implementation of "rings", plural (and it's got to predate Multics by a lot, but I can't quickly prove that), and that SMM is something entirely different. Hypervisors and there use really aren't comparable to Multics Rings.

A couple of minutes with Google only found hints that confirm my memory WRT to AMD64 and rings, and/or Intel not copying a segmentation feature added to later versions of AMD's chips.

AFAIK 64-bit linux has kernel in 0 and userspace in 3?

http://wiki.osdev.org/SYSENTER

http://www.x86-64.org/pipermail/discuss/2000-October/001068....

I tried looking at the latest 4.2 kernel tree - but the assembler/c-code that sets up and deals with sys-calls has been rather re-factored, so I'm not entirely adamant it's ring 0 and ring 3 for both 32bit and 64bit - but I think so? (From a quick glance, no sections stand out as calling out ring 3 explicitly when talking about returning to user-land -- granted I didn't do any searching over the code).

>Reading up on the capabilities of early mainframes is eye-opening if you (like me) grew up on Pentiums.

Close enough... I grew up on XTs, i286, i386, so on :) All of them way weaker than my phone (Not sure if that was what you were referring to).

However, in terms of architecture, algorithms, programming language features... It feels like we haven't advanced too much. Actually, the opposite... we are encourage now to do not be too clever on programming because processing power and memory usage is close to be a commodity and clean code is more important (which is fine but less fun).

Referring to architecture, algorithms, language features, etc obviously. They were all better on many machines from 1960's-1980's. Market kept rejecting anything that wasn't backward compatible with existing garbage and had max performance per dollar. So, dumb CPU's, COBOL, and C it is. :)

Gave examples of what features old ones had in the essay below with the first link mentioning the specific systems for further inspection:

https://www.schneier.com/blog/archives/2014/04/dan_geer_on_h...

Note: B5500, System/38, and Ten15/FLEX are all especially worth considering. Two were basically HLL machines with type-safety and interface safety enforced at hardware level. System/38 was object-based with HW- and SW-level protections plus portable microcode layer.

I'd say Channel I/O counts as one that kicks modern systems' asses. Servers have been copying it bit by bit over past ten years, maybe even exceeding it, but server OS's are inherently inferior in usage given mainframe OS's are designed for I/O offloading at core. Near interrupt-less architecture with acceleration engines makes many apps scream with performance. And would only cost $10 per CPU on desktops but would require Windows & Linux rewrites. (sighs)

https://en.wikipedia.org/wiki/I/O_channel

The modern equivalent to System/38, IBM's POWER hardware running IBM i still has the same benefits. I actually really like the concept and the way the ILE runtime works, but it's too bad that much of the platform is stuck with legacy design decisions and hasn't been modernized.

I agree with about everything you said. The System/38 design was one of the best cathedrals of old. Very forward-looking, thorough, consistent, and great for admins of the time. Still the only capability system bringing in revenue. Adapted pretty well to modern stuff but main OS's issues & stagnation hurt it as you said. I think the fact that it's pricey and proprietary kept the OSS innovation out, too.

However, the change to the AS/400 and POWER cost it one of its greatest features: hardware-enforced integrity at the object level. That's the feature that would still be giving hackers hell if it was widely deployed. The Intel i432 APX and i960MX had similar property. Interesting enough, IBM actually has secure CPU's they've prototyped and even sold to select customers. Would be great if they integrated one with IBM i at microcode, compiler, and OS levels. That plus an optional interface for new customers without legacy crap would be a huge differentiator that might give it new life.

So this generation is rewriting everything that was made and working in the 90s. Was everything written in the 90s also a rehash of stuff from the 70s/80s? Just curious, what was the equivalent of HTML/CSS/JS in the 80s?

In a way, yes. If you look at OS interfaces from the '80s and compare them with modern ones, you'll see a lot of cpu power is now spent on eye-candy but functionally they're not terribly different. Except they're all built on C++, whereas before they were in C or lower-level languages. OO was the HTML/CSS/JS of the '90s.

Could all the large software applications of today have been created without OOP, just on functional programming paradigms? If OOP was beneficial 10 years on, maybe the cross-platform nature of HTML/CSS/JS will also be vital to future applications.

> maybe the cross-platform nature of HTML/CSS/JS will also be vital to future applications.

There are already cross-platform toolkits that can deliver everything a browser engine can, faster and safely.

Face it, "web technologies" are not winning because of any massive technological advancement, just like C++ wasn't this huge advancement over C. They just managed to achieve enough critical mass to make everything else look less popular. In the '90s, OOP did that through academia and commercial push (in what was a much smaller tech sector); html/css/js did it through the accidental monopoly that is the web browser. The end result is basically the same.

> "There are already cross-platform toolkits that can deliver everything a browser engine can, faster and safely."

Nothing with the reach of web technologies. The closest I can think of is Qt, but there are issues with deploying Qt apps on some platforms.

So our choices are

• Native applications that give users excellent UX and performance

• Web apps that are equally quirky and slow on every system

As with all design decisions, it's a trade off. The main benefit of web apps is found in their cross-platform nature. If this is desirable then you may choose to sacrifice a little performance to get that.

To give an analogy, it's like programming languages. It's possible to write very fast code with assembly languages, yet their portability to other architectures is practically non-existent. Part of the reason higher level languages like C/C++ are used is because they are much more portable.

LISP, a semi-functional language, was originally invented to solve the biggest, hardest problems. Scheme, Common LISP, Ocaml/ML, and Haskell have all been used in large systems with good performance. Entire OS's were written in LISP's with some benefits that modern machines still don't have:

http://www.symbolics-dks.com/Genera-why-1.htm

Note: And some that are laughably obvious and available today lol.

So, yes, what people use today is an accident of history. That includes COBOL, C, C++, OOP languages, HTML/CSS/JS, HTTP-centric everything, and especially whatever crap is being built on them next.

If you're curious, here's the history I put together on C language and UNIX in numbered list form. You'll see how IT evolution often works in practice to give us lowest common denominator. And afterwards people swear it was product of good design and great achievement. (rolls eyes)

http://pastebin.com/UAQaWuWG

The most remarkable part of "web apps" is probably what they do not improve on:

Smalltalk had (has) messaging and decent object orientation (and you have that especially in latest js) - but Smalltalk never had one standard vm implementation - different versions had different image (ram-saved-to-disk, source code and byte-code) and vms. Javascript has common source code, but no common vm/image format.

Office Suites had rich documents with smart(ish) widgets, but no security - a macro in Excel had access to all your spreadsheet data. Web apps don't really have any good encapsulation either -- so we'll likely repeat the macro-virus era with web virus era (I'm not sure if we already are or not, there's certainly been a few self-replicating ones, that eg spread via facebook updates etc. Not sure if they generally live in the phone-apps or various web-apps. Probably both).

We already had the future of web applications within reach years ago - but apparently no-one cared: http://lively-kernel.org/

Mainframes and thin clients maybe? "All of the computing power will be over here, and the clients will be dumb and just render stuff!"

> what was the equivalent of HTML/CSS/JS in the 80s?

Depends what are looking as an equivalent. Browsers didn't exists but markup languages have been around since the 70's (mentioned for first time in late 60's)[1]

Maybe an equivalent to express GUI as resources? yeah, we called it RAD back in the day and they were quit popular among some circles. Does somebody remember Hypercard? Or even the first versions of Visual Basic?

[1] https://en.wikipedia.org/wiki/Markup_language#History

Reply on news.ycombinator.com