I certainly have! But personally I love the Erlang syntax, for me it fits the mindset of Erlang perfectly. However that statement reflects what I've seen and heard often on the topic.
Considering they are also using Clojure, LFE, or Lisp Flavored Erlang, might be a better fit than Elixr with two Lisp languages. It too has seamless interop with Erlang.
Can anyone tell me what libzdoor is? They list it among other C libraries in this article, but googling it I couldn't find any information about it. Even the github repo has no README. Very unusual not to be able to find info about a library, don't think it's ever happened to me before!
libzdoor is an extension of libdoor[1] done by Joyent. It is focusing on using doors to bridge the barrier between none global zone and global zone. Handling zone events such as boot, shutdown, deletion. It is used in a the sshd plugin that allows a process in the global zone to manage ssh keys (and ssh key access) into zones.
I saw your presentation about project FiFo in Erlang User Conference 2014. I asked you what does Joyent think about it, you said they're cool with it (gave you a t-shirt?). At that time, however, Smart Data Center was not open source.
Do you still work on FiFo, even with SDC being open? What are the main its selling points compared to SDC?
Yes I absolutely still work on fifo, actually 0.7.0 is around the corner right now and gets polished for release.
To the second question, I'll answer that from a 'out of the box' perspective so things go not off the rails because 'when doing X/Y then you can also ...' because as you pointed out both are now open source systems and with enough effort you can make them do everything. Obviously I am a bit biased here, if only for the reason that I know a lot more about FiFo then SDC but I'll try to be as objective as I can. That said I'd really would like to hear what someone with lots of experience with SDC and a bit of FiFo experience thoughts on this are.
The first difference to me is the heritage, while today both are open source, FiFo was born as a open source / community project and has taken this path from the first day. SDC is an commercial product that was then open sourced, which as Bryan pointed out in one of his talks is something really really complicated.
The second point for me, and perhaps the biggest one, is resilience. FiFo is build on the cloud premises of 'everything will fail', systems are redundant, it is master less, leverages CRDT's to mitigate the eventual consistent data model it uses. And that is something that wasn't added to FiFo but was part of it's design from the start (when you heard my talk on the EUC you might remember not always successfully ;). SDC uses a more traditional design, it was build to run on a single server and now Joyent is adding failover and replication to it. (I won't vouch for the correctness of this since it is hard to say what the design was like pre open source but it looks like this is the case from the outside).
The third advantage I see is that with fifo you can start with as little as 3GB as memory in a zone on your system then grow that system as you grow. You have to chose a sensible number of v-nodes but pretty much going from 1 to 3 to 5 servers isn't a issue and thanks to the great work Basho did on riak_core as simple as a single command. SDC comes with a own dedicated server as deployment which makes it rather resource intensive on that front. (I don't count the COOL images that run in a VM here).
Fourth, FiFo runs on vanilla SmartOS, you can not use it one day, decide you want to give it a try and it will just pick up on your setup, and then toss it away the next day and everything keeps running as if nothing ever happened. SDC has special platform images and at least in the past it wasn't as simple as not running the head node to get rid of SDC.
Tachyon, which will have it's full premier with 0.7.0 but is already available as a separate package. Developed together with Lucera it is a monitoring system for servers. Based on kstat to collect metrics and a special metric database to handle the load it can handle second level resolutions for decent installations. So that gives you historic usage and performance metrics on every server and every zone in your system, which is I think unparalleled at the moment at least at this resolution.
What we do with backups and in result the option of cold migration of VM's (kudos to the LeoFS folks at that point) is something new which can be quite interesting for some people.
Last but not least we have a dog as a mascot, which is just so much better ;).
Can somebody explain what project fifo actually does? Even after spending a bit of time on their web site, I can't tell what problem it's meant to solve, or what appropriate use cases might be.
Is it in the same general work-scheduling space as mesos? Kubernetes?
> We use vanilla SmartOS, so that there is no dependency on FiFo for your running VM’s. You could just switch FiFo off and all your VM’s would continue to just work.
Please, just 'VMs'. There's no need for the apostrophe.
The problems in no particular order and what improved:
* need to mess with gulp, and npm and their interaction vs. simply having to deal with lein
* Dependency injection is a freaking mess to debug, and it lead to an incredible spaghetti code, clojure is quite clear about where which functions come from
* The split between service, view, controller, scripts, styles, filters, directives is adding to the nice noodle feeling of it, Om/cljs does not force a layout so it's possible to arrange things as works for you
* The dependency tree from npm was HUGE and included a bunch of unnecessary dependences which made it impossible to build the UI on our build servers so we had to include the 'compiled'/distribution results of it in the git repository. Lein projects split between development deps and production deps, so everything complies nicely and only what is needed for a release is included in it.
* The split between HTML/JS/in-html-code/in-js-html is a mess. With CLJS/Om we have all code and layout in s-expressions.
* 'Everything is a callback' is in my opinion a bad programming model, still some callbacks in CLJS but a lot less and the functional model of clojure makes it easier to deal with.
* Mutable state is a pain to deal with. While not entirely gone this is a lot less of a issue to deal with since it's exceptionally clear of what is mutable and what not, in most cases you only have to worry about function parameters that's it.
If I may just air a pet peeve: Why do projects name subsystems things like "sniffle", "howl", "jingles" instead of something that gives a freaking clue about what that system does?
OpenStack does the same thing with "cinder" and "nova" and "horizon" and "neutron"
I guess it's trendy but what's with names that have no relation to function? It really adds to the learning curve or ability for someone on the outside to have a conversation about the system and understand in broad strokes what is going on.
1) It gets really complicated if every single server is named 'api-server', even with this names we ran into name conflicts and had to re-name our packages to fifo-...
2) Mnemonics, since all the names have a link to their task (jingles is an exception here for historical reasons and will be deprecated with the next release). FiFo's naming scheme is dog themed, howl is the service handling API/HTTP and communications - a dog howling, communicating with others. Snarl is the rights management server, think a guard dog snarling at new person. Sniffle is the business logic server, 'sniffing' all things out and understanding them.
3) As a developper I am spending hours a day in the code, and some of them can be really frustrating, having to deal with snarl doing something wired is a lot more pleasant then dealing with generic-aaa-server doing something wired, at least reading the name makes me smile every time.
21 comments
[ 3.8 ms ] story [ 53.9 ms ] threadPerhaps he hasn't heard of Elixir and its fluid interop with Erlang libs?
[1] http://docs.oracle.com/cd/E23824_01/html/821-1464/libdoor-3l...
Do you still work on FiFo, even with SDC being open? What are the main its selling points compared to SDC?
To the second question, I'll answer that from a 'out of the box' perspective so things go not off the rails because 'when doing X/Y then you can also ...' because as you pointed out both are now open source systems and with enough effort you can make them do everything. Obviously I am a bit biased here, if only for the reason that I know a lot more about FiFo then SDC but I'll try to be as objective as I can. That said I'd really would like to hear what someone with lots of experience with SDC and a bit of FiFo experience thoughts on this are.
The first difference to me is the heritage, while today both are open source, FiFo was born as a open source / community project and has taken this path from the first day. SDC is an commercial product that was then open sourced, which as Bryan pointed out in one of his talks is something really really complicated.
The second point for me, and perhaps the biggest one, is resilience. FiFo is build on the cloud premises of 'everything will fail', systems are redundant, it is master less, leverages CRDT's to mitigate the eventual consistent data model it uses. And that is something that wasn't added to FiFo but was part of it's design from the start (when you heard my talk on the EUC you might remember not always successfully ;). SDC uses a more traditional design, it was build to run on a single server and now Joyent is adding failover and replication to it. (I won't vouch for the correctness of this since it is hard to say what the design was like pre open source but it looks like this is the case from the outside).
The third advantage I see is that with fifo you can start with as little as 3GB as memory in a zone on your system then grow that system as you grow. You have to chose a sensible number of v-nodes but pretty much going from 1 to 3 to 5 servers isn't a issue and thanks to the great work Basho did on riak_core as simple as a single command. SDC comes with a own dedicated server as deployment which makes it rather resource intensive on that front. (I don't count the COOL images that run in a VM here).
Fourth, FiFo runs on vanilla SmartOS, you can not use it one day, decide you want to give it a try and it will just pick up on your setup, and then toss it away the next day and everything keeps running as if nothing ever happened. SDC has special platform images and at least in the past it wasn't as simple as not running the head node to get rid of SDC.
Tachyon, which will have it's full premier with 0.7.0 but is already available as a separate package. Developed together with Lucera it is a monitoring system for servers. Based on kstat to collect metrics and a special metric database to handle the load it can handle second level resolutions for decent installations. So that gives you historic usage and performance metrics on every server and every zone in your system, which is I think unparalleled at the moment at least at this resolution.
What we do with backups and in result the option of cold migration of VM's (kudos to the LeoFS folks at that point) is something new which can be quite interesting for some people.
Last but not least we have a dog as a mascot, which is just so much better ;).
Is it in the same general work-scheduling space as mesos? Kubernetes?
Please, just 'VMs'. There's no need for the apostrophe.
What specifically did you not like about AngularJS? And which version did you use?
The problems in no particular order and what improved:
* need to mess with gulp, and npm and their interaction vs. simply having to deal with lein * Dependency injection is a freaking mess to debug, and it lead to an incredible spaghetti code, clojure is quite clear about where which functions come from * The split between service, view, controller, scripts, styles, filters, directives is adding to the nice noodle feeling of it, Om/cljs does not force a layout so it's possible to arrange things as works for you * The dependency tree from npm was HUGE and included a bunch of unnecessary dependences which made it impossible to build the UI on our build servers so we had to include the 'compiled'/distribution results of it in the git repository. Lein projects split between development deps and production deps, so everything complies nicely and only what is needed for a release is included in it. * The split between HTML/JS/in-html-code/in-js-html is a mess. With CLJS/Om we have all code and layout in s-expressions. * 'Everything is a callback' is in my opinion a bad programming model, still some callbacks in CLJS but a lot less and the functional model of clojure makes it easier to deal with. * Mutable state is a pain to deal with. While not entirely gone this is a lot less of a issue to deal with since it's exceptionally clear of what is mutable and what not, in most cases you only have to worry about function parameters that's it.
OpenStack does the same thing with "cinder" and "nova" and "horizon" and "neutron"
I guess it's trendy but what's with names that have no relation to function? It really adds to the learning curve or ability for someone on the outside to have a conversation about the system and understand in broad strokes what is going on.
1) It gets really complicated if every single server is named 'api-server', even with this names we ran into name conflicts and had to re-name our packages to fifo-...
2) Mnemonics, since all the names have a link to their task (jingles is an exception here for historical reasons and will be deprecated with the next release). FiFo's naming scheme is dog themed, howl is the service handling API/HTTP and communications - a dog howling, communicating with others. Snarl is the rights management server, think a guard dog snarling at new person. Sniffle is the business logic server, 'sniffing' all things out and understanding them.
3) As a developper I am spending hours a day in the code, and some of them can be really frustrating, having to deal with snarl doing something wired is a lot more pleasant then dealing with generic-aaa-server doing something wired, at least reading the name makes me smile every time.