Hi, author of jaque here. I've been working on some other things for a little while, but I'll be getting back to jaque soon. It's quite out of date and needs to be brought up to 1.0 and cleaned up a bit before I start grousing about the stack issues I was running into on the mailing list, but when I last was working on it I was running into issues with Graal when trying to increase the java stack size. Deep but bounded head recursion is quite common in nock, and I seem to recall I needed about 8 megs of stack space (I just passed -Xss 8m or something on the command line) and Graal slowed waaaay down. That's where I left it.
Truffle tech lead here. Happy to hear you are not giving up :-) Do you mind if I include your language on the experiments list?
BTW.: I'd recommend upgrading one Truffle release at a time. So it should always continue to compile. Just fix the deprecation warnings and continue with the next version until you reached the last version. We always keep deprecations for at least one version before we remove/break APIs.
I've recently realized that most of the enjoyment I derive from building things comes from the process (figuring out neat / new ways to do things, debugging, thinking). Shipping is a necessary tedium for me. Maybe people like me have more fun fiddling with the minutiae of our tools than actually "doing cool things".
I used to feel the same way but after many years of tinkering with languages, tools, operating systems etc the novelty began to wear off and I began to feel unsatisfied by the things I'd actually shipped into the world.
These days I get far more satisfaction from putting something new that's useful or fun in front of users and I don't care much exactly what it took to get it there.
For me it was probably hanging out on HN for the last two years that changed my mindset. I used to like spending time building (as in, building forever, not shipping) things with interesting technologies and great attention to code style, etc. Right now I try to focus on making something useful for me or others[1]. Programming is now more of a tool (one of many) than an art for me (though I still love to play around with technologies and concepts).
I blame this mindshift on the prevailing focus on shipping something useful ASAP that can be seen here :).
[1] - to the point that yesterday, after spending few hours researching available software and technologies, I decided to pay few bucks for a solution that I would normally strive to code myself.
Chrome's killer feature for me is still process separation. Slow pages kill my entire browsing experience in firefox, and when I have 20+ tabs open, that can be really annoying.
Process seperation isn't the only savior to this, its just one way to compartmentalize things, intermediately, as of Firefox 7 (Aurora), there's been a massive improvement on managing compartments of memory
If the point is supposed to be "why insist on calling it GNU/Linux when xx% of it isn't even produced by GNU?", it's an ill-made point. Most of the userland (and certainly what we could call the "core" userland, especially in terms of development tools) is GNU software. The system would be pretty unusable libc, gcc, ld, make, etc.
I don't think bsd libc supports linux specifics such as fanotify and such, the libc is usually tied to a kernel. (I haven't looked at bsd libc so I may be wrong)
My point isn't that there aren't competent replacements. Obviously the BSDs in general have different userlands, as does Solaris, and so forth. But those things -are- the userland on a Linux system.
I tried hard to not make it about that but about the fragmentation of the sources of software in a modern distribution. But to your point, now with llvm we're increasingly at a point where libc, gcc, ld, make and many other gnu staples actually do have very competent replacements. As I pointed out in the post of any of the big gnu projects only gdb really has no replacement.
GNU's argument for why it deserves specific recognition over other equally and more significant contributions is uncompelling. Repeating it isn't going to make it more so.
An example would be a cron job that copies files to a backup server via scp or rsync over ssh. However, this should also be accompanied by host filters in the authorized_keys file to restrict access to specific hosts.
Using pastebin for this is wrong on so many levels.
This is why Net::SSH and Paramiko are so wonderful. Using the OpenSSH binaries through a pair of pipes is certainly a pain, but if you grok the protocol, either of those libraries can make it really easy to wire up secure pipes between machines.
