Zora, the Robot Caregiver - <AUTHOR> https://www.nytimes.com/interactive/2018/11/23/technology/robot-nurse-zora.html <comment><USER2> > "Nothing will ever replace the human touch, the human warmth our patients > need"

I remember having discussions lasting several hours with my med-school (and nursing) friends when I was at the Uni. They had the same feeling. I'm still convinced that we can and prob should replace doctors (for some of their tasks) with computers as soon as possible. For instance: given a set of symptoms and some biological metrics, a computer (an expert system) could provide a much accurate and un-biased diagnosis.

I always had the idea that in the future, "doctors" would be scientists that would be researching and helping improve AI in the medical field, but the front line would be robots/computers. At least, that's the future I would like to live in ;)

<comment><USER3> That's the root issue, isn't it. Is a simulation of something somehow inferior to the real thing? I'm not quite so sure. In my experience, it has been machines that have provided me with a certain kind of kindness and warmth that no human could ever provide for me. A machine's love would be unconditional.

<comment><USER4> It would only be unconditional if you could program it without if/then statements.

</comment></comment></comment><comment><USER5> If the "Zora" robot looks familiar, it's because it is a rebadged SoftBank (was Aldebaran) Nao[1] which have been around for a long time (I stopped working in robotics in 2012 and they had been around for a while then)

[1] [https://en.m.wikipedia.org/wiki/Nao_(robot)](https://en.m.wikipedia.org/wiki/Nao_\(robot\))

</comment><comment><USER6> > Families can visit only so much

Nothing against the robot but how do we fix the root cause of the problem? that modern lifestyles dictate leaving very little time for close family members.

<comment><USER7> Changing that won't fix the fact some families just drift apart because they're composed of individuals.

So I still see a role for those robots even in a hypothetical perfect world where nobody's ever "forced" apart.

</comment></comment><comment><USER8> What kind of a social/economic system makes us invest in this when there are billions of malnourished people willing to do something like this for close to free? Why is it that we focus so much on engineering when a lot of problems can potentially be solved using better social and political policies.

<comment><USER9> Minimum wage laws mean you'd have to pay them more than a one time cost of $18,000 which is the robot's price tag.

</comment></comment><comment><USER10> The robot itself is actually NAO from Aldebaran (now Softbank Robotics): [https://en.wikipedia.org/wiki/Nao_(robot)](https://en.wikipedia.org/wiki/Nao_\(robot\))

Zora appears to be the platform/service provider that runs on Softbank's robots.

</comment><comment><USER11> A few startups (including mine) are trying to help with human interaction in this space:

Papa (joinpapa.com): bring college students to seniors as short term caregivers

Ayuda (ayudacare.com / I am the co-founder of this one): We connect seniors in assisted living facilities with freelancers such as musicians, fitness teachers, and more.

A VC with General Catalyst wrote a useful summary on eldercare startups: [https://medium.com/@alerner_93836/disrupting- eldercare-97454...](https://medium.com/@alerner_93836/disrupting- eldercare-974546f85a2e)

</comment><comment><USER12> An undermentioned issue is that a robot can provide privacy (or perhaps only the semblance of it but still). My mother has talked about in-home care and she would prefer a machine because she doesn't want someone in her home: really she doesn't want to feel dependent. It isn't demeaning to her to have a machine take care of things for her but to have a person do so would feel bad.

Machines can't do everything but people can't either.

</comment><comment><USER13> I worry that if this succeeds and we lose the human connection to the patient there exists a slew of problems as the infirm and those with dementia aren't the best at asking for help beyond the immediate surroundings or questioning the status quo. I'm thinking wrong pills, general error handling and worst case: malicious compromise.

While its nice to see mild benefits I feel bittersweet about any successes given that I feel a better solution to this problem is more human in nature.

<comment><USER14> The piece points out one positive interaction: A patient revealed to the device/remote operator that her bruising was caused by falling out of bed. On the other hand, the dementia patient is a less reliable witness than a nannycam.

Having been in Zora's shoes for my mom I think Zora's got a long way to go, and I fear that we'll get her anyway.

</comment></comment><comment><USER15> It's easy to think, as long as there are an even number of lonely people in an area you can just pair them up and everybody can have companionship.

And yet, the world is full of buildings full of people, most of them lonely. Or all watching TV instead of talking to each other.

Walking into a room full of lonely people and trying to make them all feel less lonely is incredibly hard! There seems to be a shortage of people who are good at it. It therefore seems like a reasonable thing to try automating.

<comment><USER16> Wouldn't it be easier and cheaper to simply teach people how to have conversations with other people?

Social skills are just expected to develop naturally. But social grace and the ability to have a good conversation with someone are SKILLS -- they need to be learned and honed.

Before we start automating companionship, why don't we start teaching people how to communicate with other people?

<comment><USER15> Parents, schools, churches, and society have been trying for 1000s of years. So "why don't we start?" isn't the most useful question. Ask "why has this perpetually failed?"

I think in this case, skills aren't the limiting factor. Most people have them, but not sufficient motivation to overcome shyness and fear of rejection. Education can teach skills, but not give people motivation.

<comment><USER17> And have succeeded until relatively recently... technology isn't the solution to this.

</comment></comment></comment></comment><comment><USER18> It seems like an expensive toy, but good entertainment. If the cost can be brought down, it could bring joy to a lot of people's lives when they can't have pets.

(But why call it a caregiver?)

</comment><comment><USER19> Upcoming models include Zora the Explorer and Zora, Warrior Princess.

Flippant answer aside, what this shows us is that confused, desperately lonely people will grasp at even the most unsatisfying interactions. I don't think it points to a useful direction in robotics or emotional care. (The article was fairly clear on that at the outset, but seemed to ignore its own warning as it progressed.)

</comment><comment><USER20> When robots are advanced enough to have rights, this might be a good idea. What's next? We're spread to thin to take care of our kids so we put them in the Raiselator 3000?

</comment><comment><USER21> This isn't healthy. The robot will never provide an adequate amount of companionship required by humans. Even children don't bond with these robotic toys. The fact that elderly people are bonding with the machine is a sign of severe loneliness and not a sign of successfully creating an android companion.

I get the problem they're trying to solve though. Currently there's already a solution in modern society that solves this issue though albeit comes with it's own inconveniences... Dogs. Get these people dogs. If dogs can lead blind people than they can take care of the elderly.

<comment><USER22> Not everyone can take care of a dog or wants to.

You even admit it ("inconveniences") yet immediately dismiss it.

<comment><USER21> Your point? Obviously not everyone can take care of a dog.

Also I admit to inconveniences, but when did I dismiss it?

If I admit to inconveniences it means I am trying to present a view that covers both the downsides and the upsides.

I'll say one thing though. I'd rather have a human develop a friendship with a dog then develop a friendship with a robot toy. One relationship is healthy and humane the other is not...

</comment></comment></comment><comment><USER23> Dogs from shelters are 100000% better IMHO.

<comment><USER24> I see two problems with this: old people are fragile and training dogs is expensive.

I got a dog while my mother was in a nursing home. Additionally, my wife used to work in an assisted living facility. We would bring the dog to visit both of these, and everyone loved the visit... Except for me. It was nerve wracking. I had to keep her on a very short leash, and pay attention every second she was with an elder. In a heartbeat she can jump up or lean into someone and take them to the ground. Seniors falling is a big deal, broken bones or worse often happens.

And training a dog to be a service dog costs well into the 5 figures. I've heard $40k for a fully trained service dog, it takes around a year to do. An elder can probably be safe with something less, but I'd guess we're probably still talking $10k.

My in-laws got a dog 18 months ago and they are taking her through some of the service dog training and other training. My father in law has been out in the hospital once by the dog, and has fallen numerous times while walking her (sudden pulls or just getting mixed up in his feet).</comment></comment>


Alexey Radul on Why I Hate Scheme; Rahul Jain on DefDoc - <AUTHOR> http://ourdoings.com/boston-lisp/2008-03-31 <comment><AUTHOR> Most notable: 70 people showed up for a Lisp user group.</comment>


MacStadium: Dedicated Mac Pro Hosting and Colocation - <AUTHOR> http://www.macstadium.com/mac-pro

<comment><USER2> I will offer my translation services for their marketing copy:

"Meticulously engineered and constructed to facilitate 270 Mac Pro servers per POD while occupying only 12 square feet of datacenter floor space. "

means

"we have a cage in a datacenter with hot and cold aisles, and we bought off the shelf commercial racking and figured out how many we can fit in that racking"

"a pressurized environment allowing the Mac Pro servers to effortlessly draw in conditioned air from the central chamber, and expel it thru its unified thermal core. "

means

"the datacenter, as usual, has hot and cold aisles, so we will orient the Macs so they draw in chilled air from the big Lieberts and expel the heated air into the hot aisle; we will use blanking panels, custom cut styrofoam, or other materials to keep hot air from backwashing into the cold air aisle"

"Each server is provided redundant power, cooling, and a full Gigabit of Internet connectivity, all backed by live 24x7 support ensuring 100% uptime "

means

"we are relying on the datacenter's existing usual, typical power and cooling infrastructure, which is redundant of course; and, we will install 1 or more gigabit drops, with gigabit switches for each Mac to plug into"

(all pretty standard stuff in any DC)

"and the datacenter has remote hands capability, which we will use if needed" . Since we don't know exactly the nature of their 24x7 support, we don't know anything more.

100% uptime means only "in months that there isn't 100% uptime, you will get a credit on your bill". Check for exclusions they give themselves for maintenance windows.

<comment><USER3> "ensuring 100% uptime" without an asterisk pointing to a 300-page list of exceptions is obviously hiding it deep in the T&Cs when signing up.

The amusing part is that this sort of assurance has exactly the value you mentioned. You may be running your $20m business on this $50 service (Elvis help you), but if you're down for a month, the maximum you're going to get back is $50, and very likely only in the form of a service credit.

I'm not sure if you looked at the other pages, because OMFG WHAT THE HELL IS WITH THE GODADDY STYLE IMAGERY, but you'll note they're using EMC "Clarion" SAN devices.

</comment></comment><comment><USER4> What a waste of a Mac. I'm all for the novelty of doing something neat with Apple hardware (System X, macminicolo), but this machine isn't suited for headless closet-sitting. It's meant to be on a desk in Pixar, NBC or another live video venue, rendering things in real time and lighting up 4K displays.

<comment><USER5> Someone probably discovered that it's cost-effective due to heat and power efficiency.

It might make more sense than you think. Maybe.

<comment><USER6> It depends on the application, but the 2 vast graphics cards that make up a sizable part of the Pro's power draw will go to waste completely in a typical server application. The setup could be interesting for compute tasks or specialized render farms, but then again similar performance could be had with much cheaper components.

I don't think there are lots of applications where the use of a Mac is actually a financially sound decision in this scenario.

<comment><USER4> I agree with this. There aren't enough applications yet that even touch what the Mac Pro can do, and when they do exist, limiting them by network bandwidth through colocation seems like a dumb move. Give me a farm of Mac Minis any day.

</comment></comment></comment></comment><comment><USER7> A desktop system with a novel thermal design is being packed in tightly in a way that the manufacturer probably hasn't tested, and in a way that's going to be hard to diagnose or fix? He who dares I guess :)

What do people use hosted Macs for anyway? I guess there must be some niches, but surely everything that's great about a Mac is optimised for local usage?

<comment><USER8> OSX can only be run on Mac hardware. If you want virtual Macs within the EULA, this is what you must do. This would be attractive for people wanting to to build testing on mac machines, for example.

<comment><USER9> > _OSX can only be run on Mac hardware._

[http://www.tonymacx86.com/](http://www.tonymacx86.com/)

<comment><USER8> If you are an enterprise you would not be using modified kernels with the copy protection neutered in production.

<comment> matthew-wegner Two quick technical points:

1) OS X itself does not utilize _any_ copy protection. There are no serial numbers, call-home activations, etc.

2) You can run OS X without any modified kernels or kexts with the right mix of hardware.

<comment><USER8> There is actually. Look for the following kernel extension.

       Don't Steal MacOSX.kext

(Name might be wrong, but it's certainly there)

</comment></comment></comment></comment></comment></comment><comment><USER10> Sure, why not iPhone colocation too?

This seems like buying a Ferrari for your mailman. Well, except the difference is you'd actually get to see the Ferrari once a day.

</comment><comment><USER11> Is this purely a marketing ploy? Surely blades are much, much better suited for this...

<comment><USER12> Show me a blade that I can legally run OS X on.

<comment><USER11> I thought you could legally run OS X on VMWare - am I mistaken?

<comment><USER13> You can (per the EULA [1]) virtualise OS X on Apple hardware. VMware can run on Apple hardware.

        run up to two (2) additional copies or instances of the Apple
        Software within virtual operating system environments on each
        Mac Computer you own or control that is already running the
        Apple Software

[1] [http://www.apple.com/legal/sla/docs/OSX109.pdf](http://www.apple.com/legal/sla/docs/OSX109.pdf)

<comment><USER11> Thanks, I didn't know you couldn't legally visualize OS X on non-Apple hardware.

That's gotta be hurting them now they have no xServe

<comment><USER14> You can't. The terms quoted above specifically restrict it to virtualizing Mac OS X on Apple hardware.

</comment></comment></comment></comment></comment></comment><comment><USER15> Oddly enough, back when the cylindrical Mac Pro was first announced, a coworker and I discussed how exactly one would rack them. We came up with something very similar, but slightly asymmetric, and designed to hook into a standard 19" rack.

(This was prompted by the question of what Apple's Web site runs on if they don't make servers any more.)

</comment><comment><USER16> Is it becoming tradition now to do something like this every time a new Mac Pro is released?

[http://en.wikipedia.org/wiki/System_X_(computing)](http://en.wikipedia.org/wiki/System_X_\(computing\))

</comment><comment><USER17> 100% uptime?

<comment><USER18> I'm sold based on this alone!

</comment></comment><comment><USER19> You know what's relevant to cloud hosting? Women in short shorts and cleavage.

[http://www.macstadium.com/solutions](http://www.macstadium.com/solutions)

#sexismintech =(

</comment><comment><USER9> Is this a joke? I guess if you have money to burn.

</comment><comment><USER20> Thought that was the stack overflow log for a second had to do a double take.</comment>


What Obama's Text Message Campaign Reveals - <AUTHOR> http://gigaom.com/2008/08/24/what-obamas-text-message-campaign-reveals/

<comment><USER2> As soon as I heard about the text messaging campaign I thought to myself: Harvesting.

</comment><comment><USER3> Come on now. Really?

</comment><comment><USER4> Ugh.

3 more months of "How Candidate X is the best/smartest/most clever/wisest technology candidate"</comment>


Ask HN: Any news about StartupSchool.org? - <AUTHOR> Hey, I applied to Startup School, and the results were due today. Any news about that? Have anyone received an email? Best of luck to all of you! <comment><USER2> I just Received the email. "Thank you for applying to Startup School Online. We're sorry to say that your startup was not selected for the upcoming Advisor track."

</comment><comment><USER3> [https://mobile.twitter.com/startupschool/status/103128998490...](https://mobile.twitter.com/startupschool/status/1031289984903331840)

</comment><comment><USER4> I received the e-mail few mibutes ago.</comment>


SQLite 3.7.16 Released - <AUTHOR> http://www.sqlite.org/releaselog/3_7_16.html

<comment><USER2> Be sure to check out <http://sqlite.org/src4/doc/trunk/www/design.wiki> ... SQLite4 splits the SQL engine from the storage engine and provides public APIs for both, including the ability to run the SQL engine on top of any key/value store that provides an ordered-map interface.

In the new design a row's primary key directly contributes to its physical key, meaning lookups and iterations on the primary key involve only one scan (rather than an index scan followed by random lookups in SQLite 3.x/most DBMS). Basically the old "OID" feature on steroids, except now you don't have to design for it at all. This also means data is inherently clustered by primary key, providing further performance benefits.

The new storage engine in 4.x is exciting by itself, it's a log structured merge tree, similar to LevelDB but using the old SQLite 3.x B+tree instead of SSTables for the disk segments. Additionally it is possible to incrementally compact older generations inline as part of each write, rather than mandatorily having some unpredictable background compactor thread like LevelDB. Similar to 3.x and unlike LevelDB, the storage engine also supports interprocess locking, meaning it's trivial to write software with concurrent readers across multiple processes and a single writer.

The possibility of mixing a key/value store and SQL store, including having single transactions affecting both stores, is really exciting. The SQL engine is still a work in progress, but it should be awesome when it's ready.

<comment><USER3> "In the new design a row's primary key directly contributes to its physical key, meaning lookups and iterations on the primary key involve only one scan (rather than an index scan followed by random lookups in SQLite 3.x/most DBMS)."

Isn't this basically the same concept as a clustered index in MS SQL Server?

<comment><USER2> Yep, although I'm not sure if clustering is also a hand-triggered process in SQL Server (like it is in e.g. PostgreSQL). In any case SQLite 4.x will do it automatically.

<comment><USER4> In SQL Server that's defined at table creation time.

In Oracle it's the same: defined at creation time, but you call it an Indexed Ordered Table (IOT).

In MySQL all InnoDB tables are clustered (in that sense) because that's the only storage strategy of InnoDB.

</comment></comment></comment></comment><comment><USER5> Ha ha. The foreign_key_check command is going to be a lifesaver for me.

I run with foreign key support disabled, because the referencing ("child") rows might get inserted before the referencing ("parent") rows (I don't control the order of inserts).

Now I can just run a periodic scrub job with this command to clean out rows which didn't successfully transition from "violating foreign keys" to "satisfying foreign keys", instead of writing my own code.

Neat. SQLite is an awesome database library.

</comment><comment><USER6> Coming from the FoxPro days, I'm a huge fan of SQLite.

<comment><USER7> I didn't imagine I'd ever see FoxPro mentioned on Hacker News. That's like seeing... a Gnome vs. KDE debate on a FoxPro forum.

<comment><USER8> What about Clipper and dB3?

<comment><USER9> Started my career on dBase II, then III, then Paradox, then Foxpro (and VFP). Eventually on to DB2/2 (OS/2), Sybase, MSSQL, now all PostgreSQL.

The FoxPro / xBase market was very nice to me for about 6 years. I am happily surprised to see this still exists: <http://www.dbase.com/>

<comment><USER10> At my first job, I had a foxbase database (government built), Turbo C 2.01 (make sure to patch the FP), and a Postscript printer. We needed some reports and graphs to satisfy other agencies, what fun.</comment></comment></comment></comment></comment>


Introducing Transport Layer Security in pure OCaml - <AUTHOR> http://openmirage.org/blog/introducing-ocaml-tls

<comment><USER2> It looks like they have some odd cipher suite selection mechanic.

[https://tls.openmirage.org](https://tls.openmirage.org) negotiates TLS_RSA_WITH_RC4_128_SHA which is the second worse suite that Chrome 35 will offer by default. If I renegotiate, the server will suggets TLS_RSA_WITH_AES_256_CBC_SHA, so it looks like the server wants to change the cipher later, which seems odd.

This means it doesn't support PFS or several other advantages in the newer protocols.

I'd be very interested to know about side channel attacks which may be possible in OCaml, as opposed to in another languages - there doesn't seem to be any discussion of them here.

They also refer to the Apple Goto fail bug as a memory safety issue - that's not true, it was a programming flaw that could be made in a GCed language.

Finally, if I look at the issue tracker I see things like [https://github.com/mirleft/ocaml- tls/issues/6](https://github.com/mirleft/ocaml-tls/issues/6) \- closed, with no explanation and marked as a security concern - which gives me no confidence that the issue was addressed.

<comment><USER3> Well done on noticing the slightly random cipher negotiation. That was actually deliberately put into the demo server on tls.openmirage.org to help us get more test coverage from visitors to the site (see the [https://github.com/mirleft/ocaml-tls/tree/demo- random](https://github.com/mirleft/ocaml-tls/tree/demo-random) branch). We've mitigated most of the commonly known client incompatibilities, but there are no doubt obscure cipher-specific mitigations remaining, and the only way to uncover those is by forcing their negotiation ahead of better ciphers.

We've looked into timing side channels attacks quite a bit, but decided to focus on the core protocol support before tackling the big issue of data- dependent control flow attacks See [https://github.com/mirleft/ocaml- tls/pull/49](https://github.com/mirleft/ocaml-tls/pull/49) for discussion on the Lucky 13 mitigation that isn't merged in for example.

Editing the goto-fail reference to reflect that it's not purely memory safety (but of course we believe that more structured programming abstractions will help mitigate this class of errors). I've asked Hannes about the #6 issue as well, as that shouldn't have been closed with no explanation -- do feel free to post queries on such issues yourself as polling HN threads for feedback isn't reliable.

<comment><USER4> Clicky link to the reply is:

[https://github.com/mirleft/ocaml- tls/issues/6#issuecomment-4...](https://github.com/mirleft/ocaml- tls/issues/6#issuecomment-48383788)

</comment></comment></comment><comment><USER5> The work on Mirage is very interesting. If I understand it correctly, it may be possible to run a Xen domain with a Linux application server, and with a TLS reverse proxy in front using another Xen domain (in the form of a unikernel).

This would be fantastic and does not change a lot how you run your application, except that you get hardened crypto for free.

That's assuming that ocaml-tls has no "high level" bugs (not memory corruption related) of course, but I'm quite sure that it is way easier to review than existing TLS implementations.

<comment><USER6> One thing that concerns me is the entropy source in Xen guest domains, but hopefully that'll be worked out for the final version.

<comment><USER3> We're putting together a front/backend ring (rndfront/rndback) that will proxy entropy from dom0 directly into the guest. It'll take some time for this to percolate into the public cloud, so we'll need to do what Linux does in the meanwhile (harvest entropy from interrupt timings, attempt RDRAND, and so on).

The ENTROPY module type supports this sort of callback in 1.2.0: [https://github.com/mirage/mirage/blob/master/types/V1.mli#L7...](https://github.com/mirage/mirage/blob/master/types/V1.mli#L75)

(If you're interested in contributing, the entropy harvesting is in sore need of more eyes and help!)

<comment><USER7> /me grumbles about virtio-rng and reinventing ABIs ...

<comment><USER3> Dave Scott's added support for a low-bandwidth channel into XL with the intention of reusing virtio-rng (and virtio-serial and friends). [http://lists.xen.org/archives/html/xen- devel/2014-06/msg0293...](http://lists.xen.org/archives/html/xen- devel/2014-06/msg02931.html)

On the other hand, I disagree that we're reinventing an ABI given that:

1) virtio isn't the supported PV interface in Xen -- rndfront/back follows the same design principles as net/blk/fb/usb/pci/console etc.

2) The Xen shared-ring interface is older than virtio, and much simpler for pure PV guests such as Mirage (no PCI emulation to worry about). I do wonder what happened to that GSoC project from a few years to add virtio support to Xen though...I don't think any patches ever appeared.

<comment><USER8> s/added/currently trying to add/ :-)

For HVM guests I hope that virtio-rng would work as-is (if it could be turned on via the control path). That's definitely worth a look.

For PV guests like Mirage I'm currently plumbing through a Xen PV analogue of virtio-serial by hijacking^Wextending the existing PV console support. Since the backend for that is in qemu already it might be possible to hook up the entropy source (with all the rate limiting etc). I think the trick would be to get the guest to recognise the frontend for what it is -- I imagine the virtio-rng device in the guest presents itself as a magic hardware PCI device and 'just works'.

</comment></comment></comment></comment></comment></comment><comment><USER9> Are we finally approaching consensus in the field of systems programming that security is more important than performance (thanks to heartbleed)?

Or put differently: have we reached the point where computers are fast enough so that we can move on and sacrifice some of those abundant MIPS and extra RAM for much improved clarity in our critical infrastructure code?

OCaml could actually be a great choice for maintaining a solid TLS layer.

<comment><USER10> For the sake of moving things forward: every time we have this discussion, someone always points out that functional languages would make it easier to get correct behaviour from a crypto library, and someone always replies that garbage collection opens you up to side-channel (timing, in this case) attacks.

<comment><USER9> Interesting, I didn't know that. I always wondered why (non "functional") Ada doesn't get mentioned more often in these kinds of discussions:

[http://www.adaic.org/advantages/](http://www.adaic.org/advantages/)

[http://www.seas.gwu.edu/~mfeldman/ada-project- summary.html](http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html)

<comment><USER11> Last time it was brought up, there appeared to be some lingering confusion and issues with how the compiler and runtime was and is licensed.

The latest version of Ada is available for a (large) fee from Adacore _and_ for free under the GPL. There is also a version published as part of gcc, that trails the upstream version a little in terms of features -- but like the rest of gcc, the relevant parts are under LGPL, so not all binaries distributed to third parties need be distributed under the GPL, but can be under any licence one choose[1] -- without the need for a commercial licence from Adacore.

It would appear the lack of an up-to-date, gratis, version of Ada was a real problem for adoption at some point -- and the impression of Ada being difficult to get access to outside of large contractors put a damper on its popularity (justified or not).

[1] The "problem" with a compiler under GPL is that most compilers will have some kind of library code or language runtime that needs to be distributed with resulting binaries, thus forcing all projects to adopt GPL, rather than just the projects that build directly on the compiler.

<comment><USER12> More than price, what really hindered Ada was lack of adoption by popular OS vendors and hardware requirements for the early compilers.

Back in the day everyone was paying for compilers, the prices were the normal ones for the target audience.

Rational Software first product was an advanced Ada Machine, providing an early 80's InteliJ experience. Which followed the same fate as all special purpose computers.

UNIX, mainframe and other enterprise OS vendors that eventually provided an Ada compiler, treated it as second class citizen in regard to their main systems programming language.

Home computers lacked the required hardware to implement a proprer Ada compiler.

A systems programming language really needs to be "the language" an OS vendor SDK requires, otherwise it becomes just another application language that can also go low level.

Besides Ada Core, there are a few embedded and real time OS vendors providing Ada compilers.

<comment><USER11> > Home computers lacked the required hardware to implement a proprer Ada > compiler.

Could you elaborate? Are you thinking 80s home computers like the Amiga 1000, or more classical PCs?

<comment><USER12> Both, from the Spectrum days up to the time we could get them to run on 32 bits.

On those days I and many older than me were still writing business applications in Assembly. Compilers for higher level languages were constrained in what they could achieve in the amount of memory that was available.

And Ada did required lots of it. Funny enough I would bet modern Ada compilers are less resource intensive than C++ ones.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Looking at the development history it would appear that this project started in Feb 2014: [https://github.com/mirleft/ocaml- tls/commit/10b53cd1ebde0360...](https://github.com/mirleft/ocaml- tls/commit/10b53cd1ebde036047fb4a0d33261d07ce54432b) . Writing an (almost complete) TLS 1.2 stack in such a short amount of time is amazing! (compared to how long it took for NSS to gain TLS 1.2).

Looking forward to the next blogpost in this series.

</comment><comment><USER13> Security is too damn important to use languages that are insecure by default and that require rigorous discipline and extensive auditing, such as C and C++. The world needs to move its entire crypto and networking layer to functional languages focusing on immutability, thereby immensely reducing the surface of attack.

<comment> jude- Secure implementations require more than formal, logical correctness. They must also not leak information to adversaries--i.e. the must be free of side- channels. Unfortunately, ensuring this usually requires the developers to be aware of the low-level behavior of the underlying architecture, which is difficult in functional languages since unlike C, they abstract away behaviors of the underlying hardware that can leak information.

I suppose you could extend the functional language's type system to tag data as e.g. needing to be compared to other data in constant time, or needing to be accessed in a particular way to avoid cache-timing attacks, and so on, but this just off-loads the problem to the compiler (i.e. the problem must still be addressed, and not in a high-level functional language). But if you're going to go that far, you might as well put the requisite safe code primitives into a shared library, so if you find bugs in them later (or discover new side-channels you didn't think about earlier), you can update the library without having to re-compile and re-deploy everything affected by it.

</comment></comment><comment><USER4> Just an additional note that this is the first in a series of posts about the OCaml TLS stack. More are coming in the next few days [1].

[1] [https://github.com/mirage/mirage/issues/257](https://github.com/mirage/mirage/issues/257)

</comment><comment><USER14> On one side I see the flaws in the existing openssl and other C-based libraries and when written languages such as OCaml or Haskell those just would not happen.

On the other hand those existing libraries work. Which can not be said of the new ones. At least the Haskell TLS library has logic flaws in it that I'm wondering why it works at all. And a lot of Haskell projects use the native tls package instead of the openssl bindings. It is not fun at all having to spend two days to debug something that just works in literally every mainstream language. I hope ocaml-tls doesn't make the same mistake.

<comment><USER3> The Conduit I/O library that we're building in Mirage/OCaml allows the application to select which SSL transport layer implementation that it's linking with. Both Lwt_ssl (which binds to OpenSSL) and OCaml-TLS will be supported when it's released for exactly this reason. There's a blog post due about this next week.

As to your other complaint that OpenSSL "just works", note that numerous issues have been swept under the rug over the years (see the LibreSSL CVS logs for more pointers). I'd suggest reading this paper about the most dangerous code in the world for more background: [http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl- client-b...](http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client- bugs.html)

So when you're using the Haskell library and running into bugs, think of the time you're spending bugfixing and filing patches as a little social tax that contributes to fixing an important technical issue that threatens the stability of the Internet if it's not comprehensively addressed.

</comment></comment><comment><USER15> There's also miTLS [http://www.mitls.org/wsgi/home](http://www.mitls.org/wsgi/home) \- a verified reference implementation of TLS written in F#

</comment><comment><USER16> it would probably be a good idea to make some mention of 1/n-1 record splitting, lest confusion arise regarding the apparent "new line" between G and ET in the HTTP requests

</comment><comment><USER17> Any benchmarks? I am very interested in this, it looks really cool!</comment>