4 ms·

When I read this I raised my eyebrow. I hardly think that Lisp (1958) can be the base of the operating system of the future. Their texts are full of bold statem

When I read this I raised my eyebrow. I hardly think that Lisp (1958) can be the base of the operating system of the future. Their texts are full of bold statements about how easy and natural lisp is and how everything else sucks. Nevertheless it's interesting to look at their references: http://3lproject.org/references http://3lproject.org/references I understand than in short, the security model is about how to make sure a process does not do more than what it's supposed to. In this case it's lisp environments that provide the necessary sandboxing.

na85 11y ago
That Lisp began in 1958 is mostly irrelevant. It (Common Lisp) is a fully-modern, Turing-complete language with a first-rate object system and supports all programming paradigms. On top of that the implementations have all been regularly updated over the years and many are extremely mature and well-optimized. Do you equate newness with quality, as seems to be common on HN? Perhaps an OS written entirely in this month's JavaScript framework, deployed on Docker, using monads-as-a-service or whatever the hipsters have come up with lately would be more your cup of tea.
- rodgerd 11y ago
  > Do you equate newness with quality, as seems to be common on HN? When the link's thesis is "these OSes design years ago are old and therefore bad" it is hardly unreasonable to point out the language the author prefers is even older.
  - pjmlp 11y ago
    Because the UNIX based OS are based on PDP-11 architecture with the compromises required to fit in such systems. Whereas already in the 60s, we had hardware systems like the Burroughs b5000 that could be fully programmed in Extended Algol and Espol, with zero Assembly. The idea, as I see it, to base modern OSes in better older architectures that were lost to the mists of time. Actually the mobile OSes, with their memory safe languages seem to already be moving into this direction.
  - na85 11y ago
    >these OSes design years ago are old and therefore bad That's not the link's thesis. Equally flippant but more correct would be to say "these OSes were written in memory-unsafe languages because hardware limitations demanded it back then, therefore they are bad"
- anentropic 11y ago
  a Turing-complete programming language? How novel!
  - na85 11y ago
    My point was that there isn't anything you can do in Golang or Rust or any other FOTM language that you can't do in Lisp.
Animats 11y ago
If they came up with a good security model for applications, that would be a big step forward. Capabilities are a mechanism, not a model. Somebody has to decide who gets which capabilities. That mechanism needs to be understandable by the user. For example, Privileges for a game: - Can use full screen. - Can read own content installed with app. - Can read/write persistent storage associated with app. - Can communicate with domain "thisgame.ea.com". - Cannot run in background, access address book, ... Word processor: - Can access files mentioned in user file dialogs (file dialogs being run from a separate process). - Can transmit requests to send mail to app "mail". For any app which accesses information outside its own content and own persistent storage, the user should have the options "allow", "deny", and "fake". If a program asks for address book access and won't run without it, you can give it the "fake" option, which gives it access to a dummy address book. (I've seen something like this demoed for jailbroken Android phones.)
- arthurfm 11y ago
  > I've seen something like this demoed for rooted Android phones The amount of data XPrivacy [1] can fake is impressive. It's a shame it isn't a built-in feature. [1] https://github.com/M66B/XPrivacy#features https://github.com/M66B/XPrivacy#features
  - Animats 11y ago
    The biggest problem is the UNIX and Windows tradition that programs have all the rights of the user running them. Today, they should start out with the rights to read their own installed stuff, access their own private read/write prefs area, and use temp files. Anything more than that is at the discretion of the user.
nickpsecurity 11y ago
LISP side of things already has a bit of work toward a security model and components for robust implementation: Security Kernel https://www.kyleisom.net/downloads/security_kernel.pdf https://www.kyleisom.net/downloads/security_kernel.pdf Formally-verified Scheme http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=881F8DEAC1EE14DC88EAB49ED026CB05?doi=10.1.1.36.9989&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=881... The features could certainly be worth it. Some aspects of the Genera experience, esp productivity & holistic debugging, still aren't in modern flows: http://www.symbolics-dks.com/Genera-why-1.htm http://www.symbolics-dks.com/Genera-why-1.htm So, who knows where it will go. Betting on a semi-functional language with prior high-security and high-productivity work is a better start than most projects like this, though.

na85 11y ago

That Lisp began in 1958 is mostly irrelevant. It (Common Lisp) is a fully-modern, Turing-complete language with a first-rate object system and supports all programming paradigms. On top of that the implementations have all been regularly updated over the years and many are extremely mature and well-optimized. Do you equate newness with quality, as seems to be common on HN? Perhaps an OS written entirely in this month's JavaScript framework, deployed on Docker, using monads-as-a-service or whatever the hipsters have come up with lately would be more your cup of tea.

rodgerd 11y ago
> Do you equate newness with quality, as seems to be common on HN? When the link's thesis is "these OSes design years ago are old and therefore bad" it is hardly unreasonable to point out the language the author prefers is even older.
- pjmlp 11y ago
  Because the UNIX based OS are based on PDP-11 architecture with the compromises required to fit in such systems. Whereas already in the 60s, we had hardware systems like the Burroughs b5000 that could be fully programmed in Extended Algol and Espol, with zero Assembly. The idea, as I see it, to base modern OSes in better older architectures that were lost to the mists of time. Actually the mobile OSes, with their memory safe languages seem to already be moving into this direction.
- na85 11y ago
  >these OSes design years ago are old and therefore bad That's not the link's thesis. Equally flippant but more correct would be to say "these OSes were written in memory-unsafe languages because hardware limitations demanded it back then, therefore they are bad"
anentropic 11y ago
a Turing-complete programming language? How novel!
- na85 11y ago
  My point was that there isn't anything you can do in Golang or Rust or any other FOTM language that you can't do in Lisp.

Animats 11y ago

If they came up with a good security model for applications, that would be a big step forward. Capabilities are a mechanism, not a model. Somebody has to decide who gets which capabilities. That mechanism needs to be understandable by the user. For example, Privileges for a game: - Can use full screen. - Can read own content installed with app. - Can read/write persistent storage associated with app. - Can communicate with domain "thisgame.ea.com". - Cannot run in background, access address book, ... Word processor: - Can access files mentioned in user file dialogs (file dialogs being run from a separate process). - Can transmit requests to send mail to app "mail". For any app which accesses information outside its own content and own persistent storage, the user should have the options "allow", "deny", and "fake". If a program asks for address book access and won't run without it, you can give it the "fake" option, which gives it access to a dummy address book. (I've seen something like this demoed for jailbroken Android phones.)

arthurfm 11y ago
> I've seen something like this demoed for rooted Android phones The amount of data XPrivacy [1] can fake is impressive. It's a shame it isn't a built-in feature. [1] https://github.com/M66B/XPrivacy#features https://github.com/M66B/XPrivacy#features
- Animats 11y ago
  The biggest problem is the UNIX and Windows tradition that programs have all the rights of the user running them. Today, they should start out with the rights to read their own installed stuff, access their own private read/write prefs area, and use temp files. Anything more than that is at the discretion of the user.

nickpsecurity 11y ago

LISP side of things already has a bit of work toward a security model and components for robust implementation: Security Kernel https://www.kyleisom.net/downloads/security_kernel.pdf https://www.kyleisom.net/downloads/security_kernel.pdf Formally-verified Scheme http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=881F8DEAC1EE14DC88EAB49ED026CB05?doi=10.1.1.36.9989&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=881... The features could certainly be worth it. Some aspects of the Genera experience, esp productivity & holistic debugging, still aren't in modern flows: http://www.symbolics-dks.com/Genera-why-1.htm http://www.symbolics-dks.com/Genera-why-1.htm So, who knows where it will go. Betting on a semi-functional language with prior high-security and high-productivity work is a better start than most projects like this, though.