Live data from Hacker News

Nanobox: Local development done right

desktop.nanobox.io

51–60 of 84 posts

Re: Nanobox: Local development done right

#51

I develop in OSX, Vagrant is entirely too much overhead and hurts more than it helps. It's less work to make the app work cross-platform than to have to deal with the slowdown and the added tool complexity.

The only overhead I notice is the fact that VirtualBox Shared Folders are really slow. If that's the case, using the paid VMWare plugin can help.

Re: Nanobox: Local development done right

#52
The aggregate HN community seems to be reacting pretty negatively, but I see a lot of value in high-level "magic" tools (like this and Otto) that abstract away configuration for developers. While everyone else commenting is likely more experienced and thus feels more comfortable setting up the required config files, I am still a relatively novice web developer. Tools such as Nanobox and Otto provide a way for people like me to start using the right dev environment management processes without being overwhelmed.

Re: Nanobox: Local development done right

#53
post #18

What's your take on Nix/Guix vs containers/virtual machines for setting up development environments? (note that the former also support containers, but they provide a very systematic way to manage dependencies)

It's an odd comparision, because Nix and Guix both include tools for making virtual machines and containers. I think the better comparison would be virtualizing/containerizing traditional distributions like Debian vs. using Nix/Guix. With a traditional distro, you need to use a handful of additional tools like Vagrant, Docker, Ansible, etc. as well as several additional package managers to get everything setup. With…

I have read about half of Eelco Dolstra's Ph.D. thesis [1]. I wish all distros worked like this. I had never heard of Guix before and was about to ask how it relates to / differs from Nix, so if anyone else is wondering:

Guix:

    Specializes in providing exclusively free software.
    Based on Nix [2].
    Implementation differences, quoted from section 2.3 in [3]:
"Our main contribution with GNU Guix is the use of Scheme for both the composition and description of build processes, and the implementation of build scripts. In other words, Guix builds upon the build and deployment primitives of Nix, but replaces the Nix language by Scheme with embedded domain-specific languages (EDSLs), and promotes Scheme as a replacement for Bash in build scripts. Guix is implemented using GNU Guile 2.0 2 , a rich implementation of Scheme based on a compiler and bytecode interpreter that supports the R5RS and R6RS standards. It reuses the build primitives of Nix by making remote procedure calls (RPCs) to the Nix build daemon. We claim that using an embedded DSL has numerous practical benefits over an independent DSL: tooling (use of Guile’s compiler, debugger, and REPL, Unicode support, etc.), libraries (SRFIs, internationalization support, etc.), and seamless integration in larger programs. To illustrate this last point, consider an application that traverses the list of available packages and processes it—for instance to filter packages whose name matches a pattern, or to render it as HTML. A Scheme program can readily and efficiently do it with Guix, where packages are first-class Scheme objects; conversely, writing such an implementation with an external DSL such as Nix requires either extending the language implementa- tion with the necessary functionality, or interfacing with it via an external representation such as XML, which is often inefficient and lossy. We show that use of Scheme in build scripts is natural, andcan achieve conciseness comparable to that of shell scripts, but with improved expressivity and clearer semantics."

From my limited view, Nix has a very strong theoretical base. Do you expect any developments at that level, and do you think these hypothetical developments will be integrated by the developers of Guix, or might it at some point start ignoring improvements in the theory?

[1] http://nixos.org/~eelco/pubs/phd-thesis.pdf

[2] https://en.wikipedia.org/wiki/Nix_package_manager

[3] http://arxiv.org/abs/1305.4584

Re: Nanobox: Local development done right

#54
post #37

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.

Perhaps if they dropped the opacity on the yet-to-be supported language icons? With that said, though I'm not a huge fan of the tool itself, I do really like the site design. Great job, it definitely kept me looking around and interested in reading further.

Re: Nanobox: Local development done right

#55

The aggregate HN community seems to be reacting pretty negatively, but I see a lot of value in high-level "magic" tools (like this and Otto) that abstract away configuration for developers. While everyone else commenting is likely more experienced and thus feels more comfortable setting up the required config files, I am still a relatively novice web developer. Tools such as Nanobox and Otto provide a way for people…

You hit it right on the head. We realize that this tool isn't going to be for everyone, but it will definitely help others. We're trying to make it so that developers don't have to worry about configuring an environment and just focus on coding.

Even an experienced developer could benefit from this if they don't want to take the time to configure environments.

Re: Nanobox: Local development done right

#56

Earlier quoted context omitted.

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…

How can I pay you for this? 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-local…

Thanks for the support. Nanobox Cloud is still a work and progress, but we are hoping to open up the private beta soon. You can sign up for a beta invite on https://nanobox.io/cloud/ (Just click "Sign up for the Private Beta" and submit your email).

Re: Nanobox: Local development done right

#57

Earlier quoted context omitted.

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…

How can I pay you for this? 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-local…

Thanks for the feedback. You might want to keep any eye on Nanobox Cloud (https://nanobox.io/cloud/).

Re: Nanobox: Local development done right

#59
post #55

The aggregate HN community seems to be reacting pretty negatively, but I see a lot of value in high-level "magic" tools (like this and Otto) that abstract away configuration for developers. While everyone else commenting is likely more experienced and thus feels more comfortable setting up the required config files, I am still a relatively novice web developer. Tools such as Nanobox and Otto provide a way for people…

You hit it right on the head. We realize that this tool isn't going to be for everyone, but it will definitely help others. We're trying to make it so that developers don't have to worry about configuring an environment and just focus on coding. Even an experienced developer could benefit from this if they don't want to take the time to configure environments.

I think it's great what you're doing to reduce friction for developers.

I don't think people want to take time to configure environments. It's just that we've all been bitten by environment configuration and sometimes configuring it in a specific way matters.

Re: Nanobox: Local development done right

#60
Does anyone know what the endgame for this software is? Does Nanobox plan to offer a more premium service in addition to the basic functionalities? Hashicorp makes some revenue from premium services and I cannot imagine a tool this polished being sustainable without some sort of revenue source. Just asking, not a criticism.
Post reply on HN