I don't follow. Either that, or I don't agree. Not sure which.
I'm perfectly happy having multiple languages that are suited to different needs. Sure, I've been lured before by "one language to rule them all" style attempts at breaking this idea. I have been burned more than I've been helped by these forays. And I say this as a strong fan of lisp. A language basically designed to internalize other languages. For lunch.
(Of course, I think these are not really incompatible. When writing lisp, I've found that you are so constrained in the syntax of lisp, that eventually it almost disappears and you start seeing the language of what it is you are doing, instead.)
That said, I think the problem comes down to orthogonal changes. Simply put, when you have a language that is specifically used for one thing, effort can be placed into making sure it does that very well, at the expense of other things it could be used to do. Contrast with the languages that are designed to do anything, where you quickly find that in order to really get what you want, you have to write in very different idioms for different goals. Essentially finding that the same language is not.
Would be akin to using a band saw to make an intricately carved figurine. Sure, it is doable, but probably more effort than it is worth for a person. "Right" tools for the right job and all of that.
Would be akin to using a band saw to make an intricately carved figurine. Sure, it is doable, but probably more effort than it is worth for a person. "Right" tools for the right job and all of that.
While second is only speculative, Mirage has already demonstrated some fairly respectable performance improvements by simplifying virtual memory management.
A big issue I have with this "middleware as operating system" approach is that it invites, somewhat perversely in my opinion, throwing out your existing tools and replacing them with very, very, very similar ones that are better fits your new the middleware's paradigms. The whole "never have to leave Smalltalk", "never have to leave Emacs" etc. mentality means that everything has to be rewritten in your new middleware of choice... just so that you never have to leave it.
Except the OS has a huge amount of overhead. The whole reason why the "event driven IO", callback mess, etc. is a thing is because of the costs of native OS threads. If you don't need the things OS provides (like process isolation when running a single process server) then you're paying a heavy cost.
The thing about IT is that it has evolved over decades and as the layers were added to the stack on top of each other so many legacy design decisions are now rooted deep in to the stack - if you can blow away the whole thing and start from scratch you can get huge benefits for free. For example ZFS did the same thing with filesystems and they got many things for free just out of reexamining the initial assumptions that lead to the modern filesystems and re-evaluating them in a modern context.
Getting rid of the OS is likely impractical for most things but it can probably net you big wins in specific scenarios.
I agree, but only up to a point. Of course, it'll help you loads in specific scenarios, but in many more you'll be able to get what you want by simply hacking around the parts of the operating system that gives you those issues in the first place. As one example, I remember one person describing to me how some of the banks had set their computers to give their user mode programs the ability to perform I/O directly by adding the appropriate memory locations of the network ports to their virtual memory. It destroys the protection, but massively improves performance.
Most modern operating systems can in general be tuned or hacked to essentially get out of your way whenever you don't need them. You'd have to have a very specific use case to justify the creation of a whole operating system specifically to run your language - and an amazing business case.
Importantly, in the actual real life use cases they're not talking about providing an operating system for actual hardware that has better performance (there'd be so much expense on application support) - they're talking about providing an operating system that targets a VM model. This is a major thing - it shows (to me at least) that they're using the OS model for the purposes of additional security as opposed to anything else (especially since it's Galois who have done lots of it).
This is borderline crazy, though. The OS can have a lot of overhead, true. More likely, asking your computer to do a ton of different things is the actual overhead that is killing you.
That is, not only is "getting rid of the OS" likely impractical, you are likely to see vast improvements by simply reducing the amount of tasks a given computer is being asked to do. The gains from eliminating the OS, specifically, probably pale to the gains from just not doing as many varied things in the first place.
It's not just about misusing the features - the person writing the OS made a bunch of trade offs in both design and implementation, and while those trade-offs might be the best for the scenario where they were made in (and they don't even have to be) it might not fit your scenario, sometimes you can get huge and easy (well the pain will come from remaking the parts of the stack you needed) gains if you can go down the stack and replace those wrong assumptions.
> The whole reason why the "event driven IO", callback mess, etc. is a thing is because of the costs of native OS threads.
Nope. The whole reason why event driven IO is so popular is because of all the FUD that has been spread about the 'costs' of native threads.
Native threads are cheap as hell on modern systems. Programming in an event driven style may be more natural for some problems, but for the vast majority of cases, native threads and blocking I/O is superior.
Apache 2.4 is a pretty solid web server. So is nginx. They both have their ups and downs, but unless you have highly specialised needs, either will do the job.
The first high-level (meaning higher level than assembly) language, Fortran, took total control of the computer when the "Fortran programming system" was loaded to run a Fortran program. There was no operating system. This was in the early 1950s.
Its incredible to think that Fortran is alive and actually improving! Browsing the wikipedia article(I've not yet dived in too deeply) you find features like easy concurrency that one would expect in Go being added to a language whose closeness to C-like syntax enters uncanny valley.
"Everything is a file" is the Unix moto. But it does not do justice to that phrase. Unix has several things that aren't files (sockets are the most annoying), and a few files that are so special that they could as well have another name (like pid files).
Plan9 is an evolution of Unix that turn more things into files. Sockets, for example, are.
That just moves the problem to that remote system.
I think a better example are image-based systems such as Smalltalk, lisp, and Forth do not even need a file system (traditional forth systems are the simplest here; they had one way to read in data: BLOCK (http://c2.com/cgi/wiki?ForthBlocks))
And of course, the home computers of the '80s ran their (single) application (typically a Basic interpreter, but in the case of the http://en.wikipedia.org/wiki/Jupiter_Ace, a Forth) from ROM.
So you get a ton of code that tries to shoehorn some subset of file operations and similarities into a block structure, effectively recreating a file system. A file is a 'series of blocks' after all (that's what your inode table does it, it remembers which files start where, and a series of indirections then access the actual data blocks).
Operating systems abstract out all that common stuff, present a (somewhat) reasonable interface to it, handle multiple users if the system has those and then get out of the way as much as possible.
Operating systems that try to do more invariably fail(ed) and operating systems that try to do less end up being great for embedded work but in general not much beyond that.
I asked a computer scientist colleague what an OS is, and her answer was: Something that lets you write programs independently of the operating environment. For a time sharing or multi-tasking system, that environment could include other programs and users on the same computer. For a mainstream desktop computer, the environment includes the system updating itself, managing network traffic, etc.
In the 60s, operating systems were designed in a world where the person running the program was the same as the person who wrote the program. Today many of the security or privacy schemes start by making a distinction between the programmer and the user.
Besides sharing or "abstracting" the pieces of hardware that the app wants to control -- as VMWare or a hypervisor might do -- the operating system has one additional important role, which is to function as an agent for the user.
The apps, written by various persons, are running on a computer that belongs to the user. The operating system keeps control of the computer -- the user's computer -- in the user's hands, and keeps it from being "taken over" by the apps.
This role or function of the operating system can certainly be subsumed by a programming language / environment like Smalltalk or Java, but the idea of an operating system has a purpose that directly reflects the different interests, goals, or priorities of distinct entities interacting inside the machine.
Usually the master control program is seen as being against the users, but I'm casting it as a good guy. I think that the promise of the operating system is that it can be a good guy (for the user), even if real examples tend to fail at that job.
> The apps, written by various persons, are running on a computer that belongs to the user. The operating system keeps control of the computer -- the user's computer -- in the user's hands, and keeps it from being "taken over" by the apps.
I wonder if this can be mitigated - at least in some cases - with more disciplined and limited tools/apps.
To my knowledge, there are few programming languages that have purposefully restricted their expressiveness in order to increase how much can be proved about them. Given that "all" of them are as expressive as a programming language can be in the physical world (at least according to researchers' current knowledge), there are no non-trivial properties that can be proven about them, in the general case. In that sense, it inspires a wild-west approach - the OS can not know anything with certainty about an arbitrary app it has not run yet. So its only option - for an arbitrary program - is to try to run it and try to shield itself from whatever mischief it might do at runtime. Given this inherent and general uncertainty, creating heuristics for programming language/machine code analysis might not be high up on the priority list (if at all).
But if expressiveness is limited, there are more properties that can be definitely decided before running the program. Maybe it is possible to prove that a program will never try to access memory outside of whatever is assigned to it? This might be too difficult (in practice) to prove for a low-level language. But there certainly are languages that won't let you access memory outside of its process - java, for example, will throw an exception when the index is out of bounds. For example, languages like java could provide a proof to the OS that it will never try to access memory that it does not own? Then maybe the OS could eliminate whatever checks for illegal access of memory, since it has a proof that that kind of thing will not happen.
TempleOS [1] 'shell' operates as a programming environment - what you write is compiled and inserted into the same process that the OS is running as. It's a single address space.
I disagree strongly with this, and I disagreed in 1981 as well :-) I feel that if the programming language is your operating system then you're doing it wrong because programming languages are fundamentally verbs to express computation, not to express resource management. Of course it won't surprise anyone that I'm also a big fan of interface contracts and being explicit about the invariants the use/require. Early in its life (and much to the chagrin of the Smalltalk community[1]) Java was a "single system image" language, basically Java all the way down. And that concept worked well on embedded/appliance applications but was a poor fit for multi-function/purpose platforms.
[1] I was looking at real estate in 1998 and the old ParcPlace systems buildings were up for lease, in one of the offices was a whiteboard labelled 'Adele's whiteboard' and on it in dried white board ink was 'Java subsumes Smalltalk' and under it was written in another hand 'and the world weeps.' I expect Smalltalk to outlive Java though.
> if the programming language is your operating system then you're doing it wrong because programming languages are fundamentally verbs to express computation, not to express resource management.
But then how do you express mechanisms and policies for resource management? Would it be in some kind of... language?
54 comments
[ 3.0 ms ] story [ 89.6 ms ] threadI couldn't agree more. It's our languages that are wrong, not this statement.
I'm perfectly happy having multiple languages that are suited to different needs. Sure, I've been lured before by "one language to rule them all" style attempts at breaking this idea. I have been burned more than I've been helped by these forays. And I say this as a strong fan of lisp. A language basically designed to internalize other languages. For lunch.
(Of course, I think these are not really incompatible. When writing lisp, I've found that you are so constrained in the syntax of lisp, that eventually it almost disappears and you start seeing the language of what it is you are doing, instead.)
That said, I think the problem comes down to orthogonal changes. Simply put, when you have a language that is specifically used for one thing, effort can be placed into making sure it does that very well, at the expense of other things it could be used to do. Contrast with the languages that are designed to do anything, where you quickly find that in order to really get what you want, you have to write in very different idioms for different goals. Essentially finding that the same language is not.
Would be akin to using a band saw to make an intricately carved figurine. Sure, it is doable, but probably more effort than it is worth for a person. "Right" tools for the right job and all of that.
After that, I can't resist linking this:
http://www.dailymotion.com/video/xoe7yc_whitetail-365-seriou...
It probably helps the analogy that even though I saw every movement he made, I had no clue what he was making until I saw the actual product.
http://pharo.org
That's not '81 Smalltalk, it is the 2014 version!
Running the language runtime directly on top of Xen (http://nymote.org/software/mirage/, http://corp.galois.com/halvm, http://erlangonxen.org/ etc)
Replacing OS memory protection with a memory-safe VM (https://news.ycombinator.com/item?id=7605687)
Using hardware virtualisation to reduce the costs of OS protection between processes (http://arrakis.cs.washington.edu/)
While second is only speculative, Mirage has already demonstrated some fairly respectable performance improvements by simplifying virtual memory management.
The thing about IT is that it has evolved over decades and as the layers were added to the stack on top of each other so many legacy design decisions are now rooted deep in to the stack - if you can blow away the whole thing and start from scratch you can get huge benefits for free. For example ZFS did the same thing with filesystems and they got many things for free just out of reexamining the initial assumptions that lead to the modern filesystems and re-evaluating them in a modern context.
Getting rid of the OS is likely impractical for most things but it can probably net you big wins in specific scenarios.
Most modern operating systems can in general be tuned or hacked to essentially get out of your way whenever you don't need them. You'd have to have a very specific use case to justify the creation of a whole operating system specifically to run your language - and an amazing business case.
Importantly, in the actual real life use cases they're not talking about providing an operating system for actual hardware that has better performance (there'd be so much expense on application support) - they're talking about providing an operating system that targets a VM model. This is a major thing - it shows (to me at least) that they're using the OS model for the purposes of additional security as opposed to anything else (especially since it's Galois who have done lots of it).
That is, not only is "getting rid of the OS" likely impractical, you are likely to see vast improvements by simply reducing the amount of tasks a given computer is being asked to do. The gains from eliminating the OS, specifically, probably pale to the gains from just not doing as many varied things in the first place.
Nope. The whole reason why event driven IO is so popular is because of all the FUD that has been spread about the 'costs' of native threads.
Native threads are cheap as hell on modern systems. Programming in an event driven style may be more natural for some problems, but for the vast majority of cases, native threads and blocking I/O is superior.
Apache 2.4 is a pretty solid web server. So is nginx. They both have their ups and downs, but unless you have highly specialised needs, either will do the job.
Not true. An OS is the things that are common to all languages or applications.
Plan9 is an evolution of Unix that turn more things into files. Sockets, for example, are.
I think a better example are image-based systems such as Smalltalk, lisp, and Forth do not even need a file system (traditional forth systems are the simplest here; they had one way to read in data: BLOCK (http://c2.com/cgi/wiki?ForthBlocks))
And of course, the home computers of the '80s ran their (single) application (typically a Basic interpreter, but in the case of the http://en.wikipedia.org/wiki/Jupiter_Ace, a Forth) from ROM.
Operating systems abstract out all that common stuff, present a (somewhat) reasonable interface to it, handle multiple users if the system has those and then get out of the way as much as possible.
Operating systems that try to do more invariably fail(ed) and operating systems that try to do less end up being great for embedded work but in general not much beyond that.
Otherwise, our processes are just collaborating and if one screws up we get Windows 95.
Besides sharing or "abstracting" the pieces of hardware that the app wants to control -- as VMWare or a hypervisor might do -- the operating system has one additional important role, which is to function as an agent for the user.
The apps, written by various persons, are running on a computer that belongs to the user. The operating system keeps control of the computer -- the user's computer -- in the user's hands, and keeps it from being "taken over" by the apps.
This role or function of the operating system can certainly be subsumed by a programming language / environment like Smalltalk or Java, but the idea of an operating system has a purpose that directly reflects the different interests, goals, or priorities of distinct entities interacting inside the machine.
Usually the master control program is seen as being against the users, but I'm casting it as a good guy. I think that the promise of the operating system is that it can be a good guy (for the user), even if real examples tend to fail at that job.
I wonder if this can be mitigated - at least in some cases - with more disciplined and limited tools/apps.
To my knowledge, there are few programming languages that have purposefully restricted their expressiveness in order to increase how much can be proved about them. Given that "all" of them are as expressive as a programming language can be in the physical world (at least according to researchers' current knowledge), there are no non-trivial properties that can be proven about them, in the general case. In that sense, it inspires a wild-west approach - the OS can not know anything with certainty about an arbitrary app it has not run yet. So its only option - for an arbitrary program - is to try to run it and try to shield itself from whatever mischief it might do at runtime. Given this inherent and general uncertainty, creating heuristics for programming language/machine code analysis might not be high up on the priority list (if at all).
But if expressiveness is limited, there are more properties that can be definitely decided before running the program. Maybe it is possible to prove that a program will never try to access memory outside of whatever is assigned to it? This might be too difficult (in practice) to prove for a low-level language. But there certainly are languages that won't let you access memory outside of its process - java, for example, will throw an exception when the index is out of bounds. For example, languages like java could provide a proof to the OS that it will never try to access memory that it does not own? Then maybe the OS could eliminate whatever checks for illegal access of memory, since it has a proof that that kind of thing will not happen.
http://msdn.microsoft.com/en-us/library/33tceax8(v=vs.110).a...
http://msdn.microsoft.com/en-GB/library/930b76w0(v=vs.90).as...
TempleOS [1] 'shell' operates as a programming environment - what you write is compiled and inserted into the same process that the OS is running as. It's a single address space.
[1] http://www.templeos.org/Wb/Accts/TS/Wb2/TempleOS.html
[1] I was looking at real estate in 1998 and the old ParcPlace systems buildings were up for lease, in one of the offices was a whiteboard labelled 'Adele's whiteboard' and on it in dried white board ink was 'Java subsumes Smalltalk' and under it was written in another hand 'and the world weeps.' I expect Smalltalk to outlive Java though.
But then how do you express mechanisms and policies for resource management? Would it be in some kind of... language?