diginux

RIP Joe. Every interaction I had with you in the past was always a great time. You'll be missed, but never forgotten. Thanks for everything you've done for the Erlang community and distributed systems design.

The response from their Transport Minister 7 days ago seems fairly sane to me: http://www.telegraph.co.uk/news/2016/04/21/drone-believed-to...

A friend and I used this paper as part of an independent study in compilers, it was a lot of fun and I think strikes the right balance of concepts core to compiler construction. I highly recommend it.

Unfortunately, I do not. I would try contacting the author, you never know.

I wrote my own Lisp compiler in college using this as the foundation: http://schemeworkshop.org/2006/11-ghuloum.pdf

I will see if I can get Eric (the creator) to reply.

I have started playing with Rust and have used OCaml on and off, but recently really diving hard into it building a REST-based application from top to bottom in OCaml, including all the infrastructure bits. We are slowly making our stuff open source as it becomes useable: https://github.com/afiniate

In short, OCaml is a mature language that has been used for decades in commercial applications. I feel OCaml is the next progression for the people that got excited about distributed systems via the Erlang path and want more of the safety and reasoning that comes from a strongly/statically-typed language like OCaml. Rust may or may not take off, but I am confident OCaml will remain viable for the foreseeable future, and probably gain slow, but steady popularity as engineers see all the cool things you can do like MirageOS: http://openmirage.org/

Are you from JSC by chance? Is this from an authoritative source, or an just an observation of likeliness? Would love if they indeed do push hard for this.

Those interested in this may also want to checkout Joxa (http://joxa.org/).

A friend of mine created tilda[1], which I always enjoyed.

[1] https://apps.ubuntu.com/cat/applications/precise/tilda/

I never run an ssh server on my laptops, no reason to really. Secondly, with ssh, it requires you know ip or hostname, both which I don't want to worry about.

I wonder if there is a way they could utilize Dropbox or Dropbox-like functionality?

Compression also slows it down: http://www.spikelab.org/transfer-largedata-scp-tarssh-tarnc-...

This has been my experience in practice, too.

Doesn't seem to work for me

sender$ tar -c awesome.jpg | nc -l 0.0.0.0 12345

(waiting forever)

recipient$ nc 255.255.255.255 12345 | tar -x

tar: This does not look like a tar archive

tar: Exiting with failure status due to previous errors

I am not sure it is fair to say scp is cpu limited per se, but it is slow.

A quick article that may help you out: http://intermediatesql.com/linux/scrap-the-scp-how-to-copy-d...

This would be a great addition, I will add it as an issue, thanks!

1. In general, I am on the computer I want to send from, then I go to the computer I want to receive on. This script seems to require I be at the receiving computer first. Is there a trick to do it my way?

2. A very minor point, but you are still required to know (or at least specify) a the filename on the receiving end. My solution does not.

This is great tool and nice article. The only slightly additional requirement for this tool is you know the name of the file being sent. I actually was thinking of making this optional (for the same reasons they require it, to allow many different files).

I've added a link for udpcast to my readme as an alternative. Thanks!

For big files it would make a very noticeable difference actually, try scp with different encryption algorithms even and you will see how much it matters.

With that said, by 'quickly', I was focusing more on easiness and simplicity.

Haha, that certainly is not the case. I made a tool, found it useful, a few of my other friends find it useful, so I posted it.

Some people voted it up, I can't control that. I really could care less about karma, in fact, the critical comments (except yours) have been very useful and worth the post.

I am just being part of a community.

I made it because with the nc solution, it still required knowing the hostname.

I now see though that ncp (http://www.fefe.de/ncp/) would have probably sufficed, though it is a slightly different approach.

Sorry if you feel mislead.

Great find! I added this link, as well as ncp to the README.

It wasn't many hours and I know nc and have used it this exactly way. However, nc requires you know the hostname, an assumption I didn't want to make.

I appreciate the criticism though, it is always good to question the investment of time. In this case, I feel comfortable with it. Can't discount the joy of programming little things either.

This requires you know the IP/domain of the host. With DHCP on my laptop, this is not always the case. Yes, I know how to lookup my ip, but doing it every time becomes a pain.

Completely agreed, I assumed the project would give the perception that it isn't a fully robust tool yet, but it is always worth to make it completely clear.

Yeah, this is also on my list of todos.

I should have noted somewhere, this isn't ready for production by any means, just a first iteration of an idea I had. It is currently intended to be used on a trusted network.

Thanks for pointing this out though.