41–50 of 84 posts
Earlier quoted context omitted.
That one's not unreasonable.
It seems I can't also specify a ruby runtime, though. What makes one reasonable and another not?
It's a bit disingenuous to list a bunch of languages (along with custom logo icons) that are _presumably_ supported by nanobox, only to force visitors to drill-down one-by-one to discover that only one out of three have any support at all, and the others are just placeholders saying "please contribute". On the positive side, I guess it is better odds than a state lottery.
Magic engine detected Rails 4.2.5 app as nodejs...
Looks like it never got added as an issue on the nanobox project. I'll do that now.
While I don't think your tool is for everyone your site design is. Love the colors and clean design, goes a long way towards making me want to understand Nanobox.
I have a Dockerfile that I use to run my production. This is already built. Is there anything I can use to build a local dev environment quickly using the Dockerfile . Obviously I can use docker, but quite often new developers have trouble with docker.
Assuming this works perfectly well, all the time — this is awesome. A possible pain-point this is addressing is that apps behave differently locally and then when you move them to the cloud (aka deploy them) they behave differently.
Full disclosure: I work for Nanobox. We're prepping Nanobox Cloud for release likely in 2016 https://nanobox.io/cloud/ . With Nanobox Cloud, you'll be able to take the exact same environment configuration you have locally and deploy it to a cloud provider (starting with Digital Ocean but others will soon follow). The same engine used to run your app locally will be used in the production app. The whole workflow has b…
Note — I know many might disagree, because of very valid points, but for me personally, deployment is a nightmare. I really have no clue how that works. I didn't know SQLite3 (being file-based) needed special permissions on the .db file to be able to avoid an OSError, and the folder containing the file needed other permissions. The whole absolute-path-in-server-but-relative-will-work-locally, blah blah — This is really a irritating business for me.
Deployment ideally should be like —
$ sometool deploy myAwesomeApp
$ Enter — myServer
$ Enter — ••••••••••
$ Deploying...done!
$ Your app is live on YOUR-SERVER-IP
Too far off for many. Many might hate it, but trust me I personally know atleast 50 other developers who would benefit from a setup like this. Mostly people learning how to code, who just want to put their simple apps out there.
It's a bit disingenuous to list a bunch of languages (along with custom logo icons) that are _presumably_ supported by nanobox, only to force visitors to drill-down one-by-one to discover that only one out of three have any support at all, and the others are just placeholders saying "please contribute". On the positive side, I guess it is better odds than a state lottery.
We (I work for Nanobox) listed all the languages we hope to support mainly as an invitation to collaborate. We admittedly do not specialize in all programming languages. Engines are open-source and those who do specialize are invited to create engines for each language. We'll even create the engine for you. We just need to know what the engine should look for and how the environment needs to be configured.
What makes it different from https://ottoproject.io ?
1. Nanobox embraces Docker and the philosophy of containers. Every component and process of your app is housed inside of an isolated container. The VM only runs the Docker deamon and the Nanobox deamon. In contrast, otto leverages Docker, but is built more to conform to Hashicorp's existing toolset.
2. Extensibility in Nanobox is accomplished through engines, which are inspired by and very similar to Heroku buildpacks. As noted above, engines run inside of isolated containers inside the VM. Otto's extensibility is accomplished through Go plugins that run on the host machine.
3. Nanobox caters to the dev workflow. We'll automatically suspend and save the VM state when it's not in use. Nanobox doesn't require the VM to always be running.
Earlier quoted context omitted.
We (I work for Nanobox) listed all the languages we hope to support mainly as an invitation to collaborate. We admittedly do not specialize in all programming languages. Engines are open-source and those who do specialize are invited to create engines for each language. We'll even create the engine for you. We just need to know what the engine should look for and how the environment needs to be configured.
The php part has almost no content. Im also concerned that the custom builds are not documented, its easy to build a dev env with half a dozen rpm files thrown in, but when it comes to getting all your custom extensions etc added thats a bit harder and we cannot judge that as of right now.