On Sun, Dec 3, 2017 at 7:59 PM, Nicolas Schmidt <schmi...@math.hu-berlin.de> wrote: > Hi, > > I recently watched a recording of Theo's talk on pledge at EuroBSDCon 2017, > in which the question of memory-safe languages and their practical usefulness > came up. Specifically, someone in the audience criticized the approach taken > by OpenBSD, which (as I understand) accepts that all software is broken and > mitigates the damage caused by various classes of exploits through techniques > like ASLR, and suggested that instead one should stick to "memory safe > languages" to avoid these exploits altogether. > > As a response to this, Theo asked rhetorically "Where's ls, where's cat, > where's grep, and where's sort?", implying that noone so far bothered to > write implementations of even the basic unix utilities in such a language. > > This brings me to the question, what if someone actually bothered? Under what > conditions would you consider replacing one of the current C implementations > with an implementation written in another, "safer" language? Note that with > Cgrep and haskell-ls, there do in fact exist implementations/analogues of two > of the mentioned utilities in a memory safe language (Haskell).
IMHO it does not make any sense since (1) it was just rhetorical question probably and (2) even if you do have set of base utils written in Haskell, you would still need Haskell compiler/interpreter and due to size it's probably a no go into the base anyway. And you know the mantra: base should build base. On the other hand, it'd also be a waste of energy probably since even Haskell is high-productive language, you still compete with let's say 99% of utility code written in C. So what do you do if you need to do a bug fix in this? Rewrite 100% in Haskell or just rewrite/write 1% of bugfix in C? My bet is that if the question is not about a complete rewrite than fixing in C is more productive. Another point: look into the history. Systems usually stays written in the language where they started. Unix -> C. Cobol -> Cobol. Windows -> mix C/C++/ now also .Net. But you layer on top of those additional functionality. Look into Unix(-like) and how it drives current world of WWW and or mobile/phone/device industry. The core is still the same. Unix- philosophy kernel written in C and on top of this some additional functionality and/or web services. So to me it looks like: use language of the target system if there is a need to hack system functionality/bugfix, but let's use modern language if building functionality on top of that. IMHO quite evolutionary approach. The revolutionary approach or system written in modern language like Haskell, I'm afraid this is not going to fly also due to limited number of interested people not be able to go over certain critical people-threshhold/mass. For Haskell specifically see House, Kinetic or Hos. https://wiki.haskell.org/Applications_and_libraries/Operating_system The question for consideration is if microservices/unikernels approach is not the best combination of both worlds, e.g. having something like Mirage or HalVM based application/service running on top of OpenBSD in its VMM, that may be interesting. Unfortunately so far both supports IIRC just Xen. Have fun!
