If you are really attached to such idea and would love to work on it, your best bet is to reimplement it on your own, with a new code base. That is if you didn't sign a NDA.
I can't understand the reasoning on putting everything behind HTTP these days. Personally, I think that if a project decides to go that route it's because poor design decisions. Separation of interests should exist in software solutions.
The only bit I see that talks about something similar is, "Salmon is designed to sit _behind a traditional mail server_ in the same way a web application sits behind Apache or Nginx", emphasis is mine.
It would be nice if the documentation had some examples of how to do that, though. All it says is this:
> Salmon is best deployed behind another mailserver such as Postfix or Sendmail - much in the same way as you host a WSGI application behind Apache or Nginx.
I can't understand the reasoning on putting everything behind HTTP these days. Personally, I think that if a project decides to go that route it's because poor design decisions. Separation of interests should exist in software solutions.
It is a combination of developers wanting to have cross platform end users, while also working around restrictions in place on corporate networks. It's been downhill since
hotmail.
Lots of tools for interacting with services via http. Curl, urllib, SOAP etc etc.
Node.js / Python both have very good support for http. Soap etc, run a web server for quick file serving from command line if you want. Dgraoh and other tools can easily be interfaced via http.
This program looks interesting. Maybe it could help in the bootstrap process of tcc, though I don't know if it is written in ANSI C. On a related note, I will try to test compiling lua's runtime environment and interpreter, because I'm sure it is written using standard C already.
I'm glad I made the switch from Arch to Void. Runit is clean and simple, it does the correct job in a deterministic fashion, if something fails proper errors appear on usual logs.
I'm curious, is the compilation time that takes too much, or is it the execution time? I'm really interested in learning the language, but I don't want to end-up with programs that generate slower native code, compared to that of C. What's your experience with it?
It's not any slower than C. In some cases the compiler can actually generate better code because of stricter rules on pointer aliasing. You can also do more with only stack allocation in Ada, which is a huge win.
It does generate some extra code for things like range checks and checking invariants, i.e. things you can skip in C to write buggy code.
I know that from a technical point of view, Emacs is not just a text editor; I think it is a complete lisp virtual machine with a text-based interface that happens to be prepared for editing text by default, and thus it should be treated as such, instead of running it over as a userland program maybe one day it works as a standalone operating system, with its own kernel and JIT compiled lisp dialect. I'm saying this, because when I first started using Unix-like operating systems Emacs was one of the things that attracted me the most, but after actively using it for almost a year I saw how it moved away from the expected operation mode of a typical Unix environment, and I didn't like that. I came to appreciate the phylosophy of "One program to do one thing and do it well... make programs that work together", I consider it an elegant way to design and implement software, thus I don't see where Emacs fits on a Unix-like system. In the end, I ditched it in favor of something much more simple, fast and adecuate, this is where vis does an outstanding job, having the unique plus of using a structural regular expressions engine, and extensible using Lua. vis is small (source code and binary) and I don't have to think about what SSL implementation it should use, because there is a system library that does it for me, since vis is just a text editor, and succeeds at it.
Emacs is a wide family of text editors. GNU Emacs is just one. Originally Emacs was implemented as a set of TECO macros. The second Emacs was then EINE (Eine is not Emacs). EINE was implemented in Lisp Machine Lisp on top of the Lisp Machine OS. One of the next Emacs editors was Multics Emacs, an Emacs implemented in Maclisp for the Multics mainframe computer. Both Maclisp and Lisp Machine Lisp were full-featured Lisp implementations and thus their Emacs was a Lisp-only implementation. From then on zillions of Emacs variants were implemented. This provides a list of Emacs implementations: http://www.finseth.com/emacs.html
Then Elisp is the extension language for writing extensions (like minor or major modes) and applications using a text-editor user interface. These applications are using the programmable editor buffer as their user interface building block.
General enhanced Lisp implementations which run as a standalone operating system, but which are not special purpose for editor implementation and which are not providing an editor-based user interface exist(ed) several: MIT Lisp Machine OS (and derived), Interlisp-D, ... Mezzano ( https://github.com/froggey/Mezzano ).
Since Elisp was an uncomplete and smaller Lisp - and not a systems programming dialect like Lisp Machine Lisp - its code base is mostly like that: no lexical binding, no real multithreading, no really scalable language constructs, ... moving this language forward is a) not easy and b) not really in the core interest (the core task is being a language for editor extensions).
Also it is questionable whether its editor user interface is a good model for a general UI...
I would like to include Void as a serious, competent and elegant distribution. I've used it for a complete year, and have really come to appreciate its focus on simplicity, reminds how Arch was before they decided to use systemd.
Likewise. My initial statement was a smidge hyperbolic, as I really do like Void and run it on a Raspberry Pi. It has many of the same traits that make Slackware and pre-systemd Arch so appealing.
Before I migrated to Void, I used slackware-current extensively, it is indeed the cleanest GNU/Linux distribution I've found. Personally, I loved manually dependency resolution, but sadly didn't had the time to do it, so I ended up with Void, and it really shines on staying out of my way.
I use Void on my media PC and Gentoo everywhere else. I've considered using Void on my NAS, either that or maybe Alpine.
I'm glad you brought up this distribution. I think when we see more and more go the Docker route, we'll see more minimalist hosted systems that are Void or Alphine for hosting containers and container schedulers.
I share the same fascination you have. I'm always interested in how our brains collectively developed ways to communicate through spoken languages, it makes wonder how things will change a thousand years from now. I'm sure some developing patterns could arise.
