Systems Past: The software innovations we actually use • Hacker News Board

Re: Systems Past: The software innovations we actually use

#71

Post by thepicard » Sat, Mar 15, 2014, 11:21 AM UTC

teddyh wrote: post #70

Is it just me, or is #2 (Operating System – running separate programs concurrently independent of one another) effectively the same as #6 (Virtualization)? It is the same idea – the programmer can pretend that the program has a machine all to itself.

A modern OS is definitely a virtual machine, where each process perceives that it is running on a single CPU with its own single contiguous bank of memory. Threads are a bit of a leaky abstraction but whatever.

What is interesting is that the operating system virtualizes a machine that doesn't actually exist: fake "hardware" that can execute syscalls like read/write/exit. A VM in the contemporary sense has the exact same functionality, with a different interface. Rather than read/write as syscalls, you have to send SATA commands to disk, or commands to a network card, or whatever. Instead of an exit system call as an interface you work with a hardware interface that powers down the physical machine.

Containerization is actually a logical next step from this. Why virtualize a REAL hardware interface only to virtualize a fake one on top of it? The only reason to do that is if you want multiple fake interfaces, eg Linux and Windows. When virtualizing a bunch of Linux machines, mostly you really just want isolation of your processes. Virtualizing real hardware is a hack because Linux was not capable of isolating processes on its own, so you had to run multiple copies of Linux! Now with cgroups and other resource namespacing in the kernel, it can isolate resources by itself.

Re: Systems Past: The software innovations we actually use

#72

Post by teddyh » Sat, Mar 15, 2014, 11:41 AM UTC

thepicard wrote: post #71

teddyh wrote: post #70

Is it just me, or is #2 (Operating System – running separate programs concurrently independent of one another) effectively the same as #6 (Virtualization)? It is the same idea – the programmer can pretend that the program has a machine all to itself.

A modern OS is definitely a virtual machine, where each process perceives that it is running on a single CPU with its own single contiguous bank of memory. Threads are a bit of a leaky abstraction but whatever. What is interesting is that the operating system virtualizes a machine that doesn't actually exist: fake "hardware" that can execute syscalls like read/write/exit. A VM in the contemporary sense has the exact…

The fact that an OS supplies system calls is mostly irrelevant – it is a separate concept (not listed in the original article) which we usually call “Software Libraries”. But innovation #2 did not list the standard libraries as a point of an Operating System – the process isolation is the point. Libraries had been in use long before.

I definitely agree that hardware virtualization is going the long way around, and that more refined process isolation is the way to go. The Operating System was made for this, and it should continue to do this; there is no architectural need for an additional level of isolation.

Re: Systems Past: The software innovations we actually use

#73

Post by Pitarou » Sat, Mar 15, 2014, 12:05 PM UTC

TheZenPsycho wrote: post #61

jagger27 wrote: post #57

Earlier quoted context omitted.

What would the internet look like without encryption?

so wait. are you saying encryption… encryption was invented after 1970?

Asymmetric encryption (public-key cryptography) was developed in the 1970s. The internet would be very different without it.

Re: Systems Past: The software innovations we actually use

#74

Post by eruditely » Sat, Mar 15, 2014, 12:07 PM UTC

gumby wrote: post #2

This is an outstanding essay -- more fields need this kind of thinking. Plus it's doubly ironic having it in computation, a field that has always seemed determined to ignore history, and reinvent it. A nano nit: Yes, GC came from Lisp, but its first mention was in AI Memo #1 (the first MIT AI Lab working paper) by Minsky. I have a copy someplace -- it was only a few pages long.

Agreed, this essay was incredible.

Re: Systems Past: The software innovations we actually use

#75

Post by Dewie » Sat, Mar 15, 2014, 12:11 PM UTC

tikhonj wrote: post #14

> FORTRAN’s conflation of functions (an algebraic concept) and subroutines (a programming construct) persists to this day in nearly every piece of software, and causes no end of problems. This is exactly what Haskell solves. Not by eliminating subroutines, but by separating the two concepts out again. In particular, functions are functions in the algebraic sense, and subroutines just become values in the IO type. > T…

Something that is kind of neat is that Fortran 95 has pure procedures. Their definition of "pure" looks very similar to Haskell's.

Re: Systems Past: The software innovations we actually use

#76

Post by kabdib » Sat, Mar 15, 2014, 12:51 PM UTC

sanxiyn wrote: post #63

For some truly innovative operating system and programming language, I recommend everybody to go learn about Urbit. http://www.urbit.org/

Urbit made my head hurt. Interesting, but in an "I don't want to go there and do real work with it at all ever" way.

Re: Systems Past: The software innovations we actually use

#77

Post by nzp » Sat, Mar 15, 2014, 12:59 PM UTC

anon4 wrote: post #67

efnx wrote: post #62

Earlier quoted context omitted.

I always thought that algebraic functions are not guaranteed to be defined given certain parameters. It's just that perfectly algebraic functions don't throw errors, they silently return +-infinity. Like the asymptotes in `tan x`.

To be pedantic, tan doesn't have a value at tau/4 (or pi/2, if you swing that way). Also, algebraic functions don't return, they are - cos(0) is 1, it doesn't return 1, it doesn't compute 1, it is not a kind of computer, nor a kind of program, nor any kind of thing that consumes resources and time and returns a value; it really literally is 1. Algebraic functions are just syntactic notation. You can sit down and conv…

I upvoted you because I think this is an interesting line of reasoning, but I disagree that it's a very useful one.

You seem to be implicitly defining "computation" as that which a physical computer does (machines, biological brains...). Something that literally consumes physical resources. By that logic, a Turing machine is not a computer and lambda calculus is not about computation. As I said, you could spin the semantics that way but is it useful? Does that give us useful insights?

Functions are not just syntactic notation. Functions are, by definition, mappings from set A to set B. They don't have anything to do with notation. "cos(x)" is merely a notation, yes, but not of a number but of a function. This is an important distinction. "cos(5)" evaluates to a certain number, yes, but it's not just syntactic sugar for that number. Not to mention that functions don't need to operate on sets of numbers.

Re: Systems Past: The software innovations we actually use

#78

Post by cliveowen » Sat, Mar 15, 2014, 3:33 PM UTC

A very well-written article that promotes thinking, or better yet, re-thinking. The main point to take away is this: don't take for granted current, commonly-used constructs and architectures, they're the result of decades of tradeoffs designed to tip-toe technology's constraints. Today most of those constraints are long gone and the assumptions don't hold anymore, if we could just forget the bad parts instead of accepting them as gospel and use these five decades of experience to build something new and better, maybe we could finally stop our current methodologies from curbing our progress.

Kudos to the author.

Re: Systems Past: The software innovations we actually use

#79

Post by agumonkey » Sat, Mar 15, 2014, 3:35 PM UTC

ariwilson wrote: post #6

Haven't people been communicating information to other people as text for thousands of years? I'm not so convinced that there's a universally better mechanism for communicating with machines.

I was just reading https://en.wikipedia.org/wiki/Mail#History earlier. Interesting how they recycled resources (pool of fresh horses) on a network of relay.

Re: Systems Past: The software innovations we actually use

#80

Post by mcguire » Sat, Mar 15, 2014, 3:45 PM UTC

zanny wrote: post #25

> Virtual memory should have been extended to network resources, but this has not really happened. I get that we are already operating in heterogeneous virtual memory worlds, but network transactions are so slow. I can't see it being useful to have them as virtual addresses if random reads and writes to network space take literal seconds of round trip. That is so much worse than even disk, there is a reason networkin…

Virtualization and network resources have a long and glorious research history, although most, if not all, of the approaches are not currently in fashion. (And maybe there's a good reason for that?[1])

"Distributed memory" is one example. Once upon a time it was a big deal. I suppose that things like iSCSI could be regarded as an application, but that is the only use I know about that's at all recent.

"Remote procedure calls", "distributed objects" and stuff like that could be seen as "virtualization", if you like. I suspect all of the major advocates of these have either recanted or died off---at least I hope so. When I'm wearing my network-protocol-guy hat, I hate these things with the fiery passion of a thousands suns.

[1] See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7..., "A Note on Distributed Computing" by Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall, from Sun ca. 1994, for some early, clear, and correct reasons why making remote things look like local things doesn't work as well as you might think.