Live data from Hacker News

Why Systems Programmers Still Use C (2006)

bitc-lang.org

61–64 of 64 posts

Re: Why Systems Programmers Still Use C (2006)

#61

Earlier quoted context omitted.

A better idea would be to just build a small system whose security was obvious. Computer scientists are right to mimic mathematics. They're just mimicking it too directly. Mathematics is based on construction from simple axioms and cross-checking of different theories. Computer systems should be reduced to small parts with redundant checks against human error. If you prove a kernel "correct" that just means it will b…

I've read many of your comments on this thread, and I believe most of them to be unrealizable for non-trivial applications. Anyone can write a simple web-service, but how does one write a super low latency network file system in such a way that "security is obvious?"

Your accusation is useless because the PL tools don't solve this problem either. Currently the only tools we have in networks are cryptographic and social, and those are not provably secure. And the point is that what is considered "non-trivial" nowadays is actually "monstrously huge and self-serving". A computer is just a tool but people want to build a whole world in there. And after that they become addicts, leading to absurd rationalisations about how we need more to cure us.

Re: Why Systems Programmers Still Use C (2006)

#62
post #60
post #47

Earlier quoted context omitted.

Jonathan Shapiro is not a traditional PL researcher. He is the architect and lead developer of EROS (www.eros-os.org) and CapROS ( http://www.capros.org ), and the author of a vast number of papers on secure and high-performance reliable real-time operating systems. The confinement mechanism in EROS was provably secure (i.e. provably impossible for applications to leak permissions) by Shapiro, and AFAIK is still the…

I've been looking through EROS, CapROS, Coyotes, etc. for a bit - thanks for all the references. Is there still any forward motion here? It seems like a lot of the sites haven't been updated for a good number of years. A notable exception was BitC, which was news from 2010 - still not that recent.

Not that I'm aware of, unfortunately. I haven't followed things much over the past 2-3 years, though.

I suspect there are two forces at play:

1. Building a pure capability-based operating system has minimal payoff. While personally I believe the result will be an amazingly reliable, high performance, secure system, the fact is the operating systems we have today are apparently "good enough" that nobody is interested in funding further work in this area (AFAIK Shapiro and others did form a venture in this regard; what came of it I don't know). Keep in mind that much existing software will have to be re-engineered, and a good part of the OS utilities redesigned since if you're going the pure capability route the significance of files becomes pretty much purely a user thing.

2. At a higher level, in my opinion (as an amateur capability-based systems theorist) the benefits of distributed capability-based systems have already been realised as the shape of the evolving web, albeit on much cruder foundations than those designed as part of the literature. Cookies + URLs are pretty much capabilities, and web services (including web sites!) are effectively distributed objects. Javascript + HTML have fulfilled the dream of being able to ship and run data, code and user interfaces remotely, which is the foundation for an unplanned human + computer usable distributed ecosystem.

Javascript, while not the cleanest language, is a solid language for a capability-based system (in terms of capability rules: everything is an object, objects can only be accessed via references [capabilities], objects references can only be acquired by (a) creating the object or (b) by receiving a capability), i.e. capabilities cannot be forged. If you're interested in what an even more pure approach, designed by people who really know what they're talking about, would look like then take a look at http://www.erights.org and http://www.waterken.com .

In this sense, the first true modern capability-based operating system will probably be the first true web operating system.

I think it's pretty cool, and a confirmation of the ideas in Gnosis, KeyKOS, EROS, Coyotos, CapROS, E, etc. that the natural evolution of the largest distributed system on the planet (the Internet) effectively took the form of a distributed capability-based system.

Re: Why Systems Programmers Still Use C (2006)

#63
post #56
post #55

Earlier quoted context omitted.

It is possible to do syscalls in Java. Following your example there are also JVMs coded in Java.

It is certainly not possible to do syscalls in "Java". A system call is a special CPU instruction (e.g. INT, SYSENTER) not accessible to or defined in the Java VM specification. What you do to effect a syscall is to call a JNI function to do the work. JNI is a C (!) API, defined in terms of the C (!) ABI for the platform. And sure: you can generate native machine code in Java, just as you can in python or bash or eve…

Depends what you consider Java, as there are VM extensions coupled with compiler magic that allow it.

One such example is the Jikes VM:

http://jikesrvm.sourceforge.net/apidocs/latest/org/vmmagic/p...

Or the Sun's research in writing drivers in Java http://labs.oracle.com/techrep/2006/abstract-156.html

Re: Why Systems Programmers Still Use C (2006)

#64
post #62
post #60

Earlier quoted context omitted.

I've been looking through EROS, CapROS, Coyotes, etc. for a bit - thanks for all the references. Is there still any forward motion here? It seems like a lot of the sites haven't been updated for a good number of years. A notable exception was BitC, which was news from 2010 - still not that recent.

Not that I'm aware of, unfortunately. I haven't followed things much over the past 2-3 years, though. I suspect there are two forces at play: 1. Building a pure capability-based operating system has minimal payoff. While personally I believe the result will be an amazingly reliable, high performance, secure system, the fact is the operating systems we have today are apparently "good enough" that nobody is interested…

Thanks, I really appreciate the info. Sorry for my slow response, I hope you see this.

Building a pure capability-based operating system has minimal payoff.

Given the massive security problems we see today, if capabilities are the right solution (are they?), it seems like the payoff could be massive. It seems like "mass adoption" would be hard to achieve (except in the really long term), but it seems like it would be possible to find early adopters who "really really" need good security (e.g. certain military applications, maybe?).

At a higher level, in my opinion (as an amateur capability-based systems theorist) the benefits of distributed capability-based systems have already been realised as the shape of the evolving web, albeit on much cruder foundations than those designed as part of the literature.

This is extremely interesting. Reminds me of the idea behind the "separation kernel" which is supposed to mimic in software the security that can be achieved by connecting systems only over extremely well-defined channels (e.g., the systems are physically disconnected except for an ethernet port that is very well controlled). I can find a refence on security kernels if you're interested and not aware of them already.

Anyway, it does seem to me that there are lots of applications (e.g., embedded applications) where distributing everything over the Internet isn't really going to work (not that you're suggesting that). I'd really like to see people tackle security for this kind of system in an entirely new way. Maybe capabilities is part of that.

Post reply on HN