The sad state of web app deployment - <AUTHOR> http://eev.ee/blog/2015/09/17/the-sad-state-of-web-app-deployment/ <comment><USER3> As another old-school type, I really enjoy this rant. And my understanding is that the piece of software in question is a nest of snakes, so I can well believe that there is no good way to install it, only bad ways and worse ways.

But having tried out Docker for some production deployments, I think that it (or some less goofy successor) is the way forward. You get a sealed box with all the necessary dependencies, and the box has just enough holes poked in it that you can connect up the bits you care about. It turns apps into appliances, not things you need expert craftspeople to lovingly install.

As much as I have enjoyed 25 years of doing everything on an OS whose conceptual model is a 70s university department minicomputer, this era is coming to a close. We already know it's a poor match for existing hardware and use cases because we now mostly run it in virtual servers. But "virtual server" is the new "horseless carriage". It's a phrase that tells us we are living in a future we don't yet fully understand.

<comment><USER4> I love Docker; it's solved a lot of problems for me. But this article highlights the laziness that it can enable: there has to be a middle ground between traditional package management and all of the curation/QA that goes into getting stable releases out to multiple distributions, versus chucking shit over the wall into a git repo with a Dockerfile and calling it done.

It's a better, more isolated mess - but for anyone trying to enforce configuration policy into all of the running services in their environment, untangling gortesquely basic shit like not granting superuser privs on a database to your webapps - which would never fly in a traditional distro package - becomes even more work than the old source tarballs with INSTALL.txt.

<comment><USER5> > the laziness that it can enable

This is the entire value proposition of all successful technology. Dubious business practices notwithstanding, all successful yet imperfect technology is successful because more people found it let them be lazier than the competition. But in reality of course it's not laziness, it's efficiency. They can get on with other tasks sooner than before.

<comment><USER4> > But in reality of course it's not laziness, it's efficiency. They can get on > with other tasks sooner than before.

Indeed, and I use Docker myself to improve my own efficiency, and I've seen great stuff built with Docker that has been architected well.

However, it is painfully obvious that without the pressures that used to force most developers to keep their shit sane, there's now more workload for serious users that actually need to untangle this mess in order to support, secure and get stuff deployed.

</comment></comment></comment></comment><comment><USER6> Wow. This is ridiculous.

"I've got a weird set up OS for a reason, but this software should work even though no one else would ever run this."

"Whatever- this database should work, even though I'm using a 4 year old version of the free software(that the docs specifically say needs to be a newer version)."

"Also, I'm extremely inexperienced installing Rails and Rails apps, and despite the fact that it's a language and server that we literally teach the newest of the new, it's just impossible to do anything with."

This isn't a story about the state of web app deployment, this is about the state of the server from hell. This sounds like the kind of thing you hear out of megacorps with 20 year old Mainframes.

Should open source be supporting such convoluted, needlessly minor cases of awful environments?

<comment><USER7> Yes, my OS is slightly "weird" for reasons I did not choose. Funny story: while I was trying to figure out what the hell RVM was doing, I mostly ran across people running OS X who had the same setup: 32-bit OS on a 64-bit chip. (And for what it's worth, Python native extensions build for the architecture of the Python executable — you know, the thing that has to load them — rather than the architecture of the machine.)

I never complained that it didn't work with an old database. Ubuntu's versioning was just a fun surprise. I don't see why it _wouldn 't_ work with Postgres 9.1; I just figured I'd do the upgrade while I already had my foot in the door.

Maybe if installing Rails apps is still a huge headache after the fourth or fifth time I've done it, something is wrong with Rails. Maybe.

I have a fairly mundane server running the latest Ubuntu LTS with all stock vendor packages. If your app is such brittle crap that _this_ is the "server from hell", well, it's no wonder everyone is using Docker.

<comment><USER8> 32 bit x86 setups are very rare now under Linux, and you are really on your own - people no longer test with them and some software no longer supports 32 bit (eg Docker; I gather it will go multi architecture soon but I doubt much stuff will be built or tested on 32 bit x86 anyway). As your hardware can run 64 bit you have no reason to run 32 bit.

<comment><USER7> I hope you can imagine why I might not want to reinstall the OS and have to redeploy half a dozen other things, just so this particular one gets easier.

<comment><USER8> Because you are managing your servers as pets not cattle? Because you did the installs manually and can't replicate them? Thats what you need to fix, with automated deployments that is a non issue.

</comment></comment></comment></comment></comment><comment><USER9> The tone of this article is very upsetting. It begins with "I like to think I'm pretty alright at computers", but frankly I don't really agree that this is the case. Good at programming, maybe, but clearly not very good at ops.

Rather than accept that there are skills and experience they don't have, the author instead chooses to blame the entire world for their ignorance. The frustration on display is understandable and real and I totally get it, but the attitude is less forgivable.

Faced with a problem, instead stopping for a hot second to read some documentation, the author instead concludes that Docker is garbage, does some insane shit and then claims that the software industry has failed them. What incredible arrogance.

This article says way more about the character of this person than it does about the state of web app deployment.

<comment><USER10> Your reaction to "server software deployment could be better" is to scoff at the problems and ad-hom the author.

[http://i.imgur.com/SMPYGEU.jpg](http://i.imgur.com/SMPYGEU.jpg)

<comment><USER11> The author's reaction to "we've decided to try and simplify deployment of our hideously complex app" is to ignore the supported deployment, bury themselves neck deep in the guts of the complex deployment the devs worked to abstract away, and then rage about it. I'm not really seeing "server software deployment could be better" as a fair read of that.

<comment><USER10> His point is not "I don't know how to deploy a Rails app", it's "there is no standard way for a server program to tell the OS how what services to configure, or to query the OS for what services are available. Instead of fixing this, we wrap a pre-configured-OS-image and run it inside our OS. This is daft". As well as "the instructions are incorrect and incomplete, and that's normal".

e.g. _Set aside the oddball tool breakage and consider that if you follow the instructions to the letter, this web forum requires: cloning (not installing!) the software's source code and modifying it in-place. Copy-pasting hundreds of lines of configuration into nginx, as root, and hoping it doesn't change when you upgrade. Installing non-default Postgres extensions, as root. Running someone else's arbitrary database commands as a superuser._

and

 _You'd think that a web app could just have some metadata saying "I need Postgres and, optionally, Redis", but this doesn't exist. And the other side, where the system can enumerate the services it has available for a user, similarly doesn't exist. So there's no chance of discovery. If you're missing a service the app needs but failed to document, or you set it up wrong, you'll just find out on the first request._

and

"What we should have by now" section.

and

 _And I'm really not picking on Ruby, or Rails, or this particular app. I hate deploying my own web software, because there are so many parts all over the system that only barely know about each other, but if any of them fail then the whole shebang stops working._

<comment><USER12> Service discovery, orchestration, and on-the-fly config/environment changes are things that are solved by tools like consul and mesos (to scratch the surface). The ops world is so much more than just dockerfiles. There is absolutely a "chance of discovery". Using consul has helped us move to zero- configuration, discoverable microservices. Then for the more hobbyist stuff, there's docker-compose. Not looking into the options and ranting is not the same as there not being any options.

</comment></comment></comment></comment></comment><comment><USER13> > See, I actually have a 64-bit kernel, but a 32-bit userspace. (There's a > perfectly good reason for this.)

Well, maybe there is, but a lot of this article seems like "the sad state of nobody has this web app set up to be installed on my frankenlinux."

</comment><comment><USER14> This is a weak article. The author's never worked with Docker before, so got tripped up by a few gotchas (but seriously, installing a third-party PPA isn't that hard or weird), but it doesn't take that much googling or trial/error to figure out how to do it right.

And the point of that is, once you know Docker, now installing just about any set of dependencies becomes a skill you know. I've never worked with Discourse. I've never worked with Rails. But because I've done Docker-based deployments, I bet I could indeed get it up and working in 30 minutes.

<comment><USER15> I've used docker before and my install was to a clean ubuntu 14 64bit - discourse installed + up and running in about 3.5 minutes. I have never worked with Rails or Ruby, or had to touch rvm for this case.

Incidentally, my hosting machine is basically clean - I don't use it as a personal or dev box, it does not have a ton of random userspace stuff in 32bit, it just hosts things.

</comment></comment><comment><USER16> Ok, I get it. I've felt like writing this article many times. I didn't, but I give the author props for letting off some steam in a constructive way. However... this statement drove me a little bonkers...

>> The 30-minute claim came because the software only officially supports being installed via Docker, the shiny new container gizmo that everyone loves because it's shiny and new, which already set off some red flags. I managed to install an entire interoperating desktop environment without needing Docker for any of it, but a web forum is so complex that it needs its own quasivirtualized OS? Hmm.

I understand the reflexive dismissal of things that become popular topics. I'm guilty of it myself repeatedly, most recently with "microservices." But sometimes technologies become popular because they are good and useful.

I haven't run into Docker's 32-bit install problem. They should fix that. But to dismiss the whole technology as some sort of obviously useless quasi- virtualized OS mumbo jumbo is taking the rant too far. Dependency isolation is a good thing. Deploying server applications with one command is a good thing. Knowing that your runtime environment is always the same is a good thing. Having a simple source controlled script that completely describes that runtime environment is a good thing. Some people try to use containers for unreasonably complicated things, or to hide unreasonably complicated software, but that is not an indictment of the technology. It's popular for a reason.

<comment><USER4> As a happy Docker user with a lot of respect for what Docker has achieved, what concerns me is that Docker is clearly an enabler for people to totally abandon proper release and dependency management along with sane sysadmin friendly configuration.

I can't tell you the number of times I've hoped to use a public docker image or just the Dockerfile, only to spend hours futzing with it because I was unhappy with the grotesquely insecure configuration or because I needed to work around a bunch of assumptions that are invalid once I've tuned the Dockerfile for my environment.

<comment><USER8> Fix the insecurities upstream or dont use the software. Else upgrades will be a nightmare too.

<comment><USER4> I agree, and I do (if I end up actually keeping a piece of software running).

It's also quite likely that a pre-built docker image isn't going to satisfy everyone's deployment requirements.

Starting out with a philosophy that you'll make all the configuration and security choices for every user of your project isn't a great start, and that's how I read all these hard-coded assumptions.

</comment></comment></comment></comment><comment><USER17> GitLab is the other large open source Rails project. We choose to package below the container level with Omnibus packages. These run without all the Docker dependencies and install in 2 minutes. We did this because many of our users could not run a recent/custom kernel with Docker. We're very happy with the choice and are able to run the Omnibus packages on top of our images [https://gitlab.com/gitlab-org/gitlab- ce/tree/master/docker](https://gitlab.com/gitlab-org/gitlab- ce/tree/master/docker)

That being said, it is still a bit silly how hard a Rails app is to install.

</comment><comment><USER18> There actually is a point. I'm not a rails developer but as a Python developer I can definitely say deploying applications is far more difficult than it should be. To deploy a simple Flask app as FastCGI I had to download some nasty .fcgi file from MIT's 6.170 course website to detect code changes and reload the app. To deploy with nginx+uwsgi I spent ages configuring it and with poor documentation.

Seriously, things like uwsgi should have an "auto-configure" feature where when an error is encountered with a dependency, it searches the hell out of your /usr filesystem and caches the resulting configuration. If a module is missing, automatically try to apt-get and pip install it. Nginx should portscan the hell out of localhost and detect uwsgi servers. Install uwsgi if a wsgi app is detected but uwsgi isn't installed. Write the .ini file automatically. This process is so automatable that there really should be a "magic deploy" feature where I can just drop a Flask app as /var/www/html/some_app/index.py and it should be instantly up and running at [http://localhost/some_app/](http://localhost/some_app/) with zero questions asked.

</comment><comment><USER19> Nice article, I can empathize having recently inherited a PHP project which included a puphpet (vagrant/puppet) VM. It wasn't touched for a some time so the configuration was a few months old.

After installing the required dependencies (downgrade VirtualBox etc) all that was left was: vagrant up. My lord, what had I gotten myself into. Que problems with the configuration, ruby version during provisioning, paths, puphpet had gone through multiple breaking changes in the meantime, the documentation was unhelpful. The only inspiration were GitHub issues on tangentially related projects ... all I know is it was 3am having stared 6 hours earlier.

Then, in a moment of madness I deleted everything and created a completely new/fresh puphpet configuration using the puphpet site. Again during provisioning I was met with a problem, there are non-ascii characters in the php-fpm upstart configuration file (the authors name!). Luckily, this was an issue already discovered a couple of hours earlier, so a small change to that and the app was up and running. It was 4am.

Needless to say, I was very frustrated with this state of affairs of these supposed aids to setting up the dev environment. Granted, my mistake was going in the wrong direction trying to fix an outdated configuration and all the problems it generated rather than just generating the config again, but I had never used this tool before, and hadn't looked at the PHP ecosystem for the past few years, it seemed crazy at first that a config which worked in the past, presumably, would not work on my very mundane Ubuntu dev environment.

<comment><USER20> Oh gosh, puphpet and vagrant. Had a similar architecture with a Silverstripe framework recently inherited, it was well documented and all, but due to new versions everything was broken.

I ended up doing deployment with git pull.

</comment></comment><comment><USER21> I've been doing Rails now for _a decade_ , and I love ruby, but Rails is not suitable for installable open source software. It is one of the worst languages for that use case. The whole mentality of the Rails community runs counter to the goals of providing easily deployable packages. There is certainly a lot of low-hanging fruit to work on these issues, but I don't see it becoming a priority anytime soon because if you value these things you're probably already using some other language than ruby.

The sweet spot for Rails is custom apps that is continuously maintained over a long period, or discardable prototypes. It is not a good choice for deploy- and-forget, or organizations without any in-house programmers.

</comment><comment><USER22> I was going to come comment that there must be a good way to solve this, since the Ruby community has such a rich ecosystem of tools.

Heroku, for example, has a nice one-click deploy button for Rails (and many more languages/frameworks). It works straight from the source code, such as with this open-source rails app, and it's really quite impressive:

[https://github.com/heroku/starboard#deploy-the- app](https://github.com/heroku/starboard#deploy-the-app)

The author also calls out error reporting as being terrible. And there's also great tools for managing that, such as newrelic and airbrake.

So surely this author was just unused to the tool ecosystem, I thought. What a perfect opportunity for a constructive yet snarky comment! But lo and behold, discourse has deprecated all non-docker installs:

[https://github.com/discourse/discourse/blob/master/docs/inst...](https://github.com/discourse/discourse/blob/master/docs/install- HEROKU.md#warning-this-guide-is-deprecated)

I was, and am, completely baffled at that decision. And I learned a valuable lesson about trying to out-snark snarky blog posts.

<comment><USER11> Supporting multiple deployment options introduces a lot of overhead, and Docker (in particular) seems really good at reducing deployment overhead for both developers and admins. I'm not sure why it's a bad thing when it means that the team can focus resources on a single canonical deployment method that just works. Docker containers can also be run on a variety of public cloud services, so while Heroku may not be available, pointing your Dockerfile at EC2 or GCE shouldn't be too hard?

</comment></comment><comment><USER23> If you use 32bit Linux in 2015 you deserve the pain you just endured.

The problem is not the state of deployment (which is still admittedly quite bad), it's the state of your system.

Install a fully 64bit version of 14.04 and watch all your problems just disappear.

</comment><comment><USER24> Two things come to mind

1\. Tinfoil hat time! "Pisshorse" make money off of hosting their own software. So they are financially incentivized to make it as difficult as possible to install yourself, but at the same time they get to go "woooo, open source" as much as they like.

I'm convinced Oracle did the same sort of thing by making their DB product impossible for normal people to understand, in order to charge outrageously expensive consulting fees to companies. Or so I hear; I've never used it so I could be wrong.

2\. Your users aren't always who you think they are. I learned this one switching from back-end/n-tier work over to front-end CMS based web dev. Yes, the users are the people browsing the website, but the users are also the people trying to use the damn CMS, so the website UX and design extends to those people as well.

Meaning, instead of forcing your hapless marketers to use some crazy admin panel with thousands of options and checkboxes, or even try and edit XML configuration (I've actually seen this), any time one extends the functionality of a CMS, creating some custom front-end UI to control it is a basic necessity.

In the same vein, any sort of software (and hardware! printers, tools, cars, whatever) has to consider the installation and maintenance of itself as a UX/design concern and the fact that it has multiple domains of users.

<comment><USER7> I observe that they'll happily charge you $99 to install it on your machine _for_ you.

<comment><USER25> Nope, that's on a 64-bit Digital Ocean machine that we provision for you. The only secret sauce in the $99 install is the Mandrill reseller code.

</comment></comment></comment><comment><USER26> Really, 90% of this article is an argument _for_ docker. His docker installation annoyance was nothing compared to the pain ensuing from his decision to chuck docker out of the window.

<comment><USER27> This. He says "We need to find a solution to install those apps with a dozen dependencies, config files, crontabs and daemons". Well, although it may not be mature security wise, this solution is still Docker.

</comment></comment><comment><USER28> I had the same trouble setting up discourse, so I setup a template on Nitrous using Docker that you can definitely use to get Discourse up and running in 30 seconds. (I just confirmed, I went from no environment to running discourse in less than 30 seconds). Just `cd code/discourse && ./start-app`.

This, IMO is where Docker shines. It shouldn't matter if it's setup with a microservice 12-factor architecture or if everything is setup in a monolithic VM-like container. I don't have the patience for ops -- I just want something that works. That's the point of having isolated, replicable containers.

In any case, I encourage you to try out the discourse container on Nitrous. I was actually surprised it happens to be the least popular container for us. I assumed because it's such a pain in the ass to get started, that it would be more popular =p

</comment><comment><USER29> So I actually remember running into the "Unable to locate package docker- engine" issue a while ago, and it seemed like an issue on Docker's end because for me, the issue actually only lasted about half a day before it started working again without any changes on my part.

So I think in the end this was just a case of _really_ unfortunate timing, because if it weren't for the Docker installation issue, the only real complaint left in this post would have been the fact that the official method of installing Docker was to curl a script and pipe into sh[1]. And the rest of the post would have been singing praises of how amazing Docker is to be able to take setting up a Rails app along with all its dependencies and turn it into such a simple, painless process.

[1] Which is a perfectly valid criticism, by the way. They should really document the much saner method of installing through their official repos:

[https://blog.docker.com/2015/07/new-apt-and-yum- repos/](https://blog.docker.com/2015/07/new-apt-and-yum-repos/)

<comment><USER14> Yeah, the really weird thing about this article is that it's all snarky about Docker, and then it goes off into weird manual-install land (which makes about as much sense as saying "I couldn't get the .msi installer to run, so I started copying files around and registering DLLs by hand" \-- maybe you'll get that to work eventually, but it's never going to be pleasant), and then makes a call for something that... solves the problems Docker solves.

The whole article is basically a "there has to be an easier way!" infomercial for Docker, only it doesn't realize it.

<comment><USER30> It's funny because the project actually provides a Vagrantfile for creating a regular VM image.

<comment><USER31> Vagrant's only intended as a development solution, though, not for production deployment.

</comment></comment></comment></comment><comment><USER32> I have to say that Docker used to be very annoying to work with on Mac OS X but with the latest release of Docker Toolbox it has a much better "works out of the box" experience.

The article is pretty ranty but I can agree with the author that many things nowadays are way more complex than they have to be. As a plug, I'm going to say that this is one of the reasons why we started the CloudMonkey.io project. It lets you deploy a docker container with no fuss to production. It's up to you, however, to ensure that you don't over complicate your system unnecessarily.

I've done the mistake in the past where very early on in the project I started using a web server, Redis, ElasticSearch, MySQL, memcached, RabbitMQ, etc.

In most cases, more than three moving pieces only bring you headaches. Now I always try very hard to keep things simple to at most a web server and a database, plus maybe a memcached caching layer. If you need to have a queue or full text search functionality, I'd try to bring it in as an outside service.

</comment><comment><USER20> What's most worrying with all that Docker bullshit is updating. We're going to end up with physical hosts with dozens of fire-and-forget VMs on them and each one filled with security holes.

</comment><comment><USER33> I agree with most of this rant, but not with this too common mith: "Only one thing can bind to port 80 and it has to run as root". I generally use the following command <pre>setcap 'cap_net_bind_service=+ep' /usr/bin/nodejs </pre>

Just learned the trick to become root when you belong to docker group. Awesome

</comment><comment><USER34> >"Let's just say it rhymes with "piss horse"

I think he's talking about Discourse [1]. I tried Discourse few years back when it was released but it was too bare-bones at that time. Haven't tried it recently.

[1]: [https://github.com/discourse/discourse](https://github.com/discourse/discourse)

<comment><USER35> I really don't understand why a forum needs 2GB of RAM.

<comment><USER31> It doesn't; 1GB is the minimum. We have to fit Redis, Postgres, Ruby, Sidekiq, and 2 Unicorns in there. There are a bunch of fairly active instances on 1GB RAM, which works fine. If your community grows a lot you'll need more resources, of course.

</comment></comment></comment><comment><USER36> Some other sad things, from the top of my head:

\- Besides a web app, we must also create mobile apps, and they usually don't share much code. It would be much better if apps could just run HTML and Javascript instead, and still be integrated like native apps are now.

\- Every web app that is deployed now is not guaranteed to work X days into the future. In fact, it often breaks. We need better guarantees for this.

\- Browsers are incompatible in subtle and not-so-subtle ways.

\- It is way too complicated to write a web-browser. The number of abstraction-levels combined is too large. Security problems are therefore unavoidable.

\- On the front-end, React is a suboptimal solution because it requires O(N) time and energy for simple O(1) updates. We need smarter incremental computation techniques.

\- The primitives for the web (HTML+Javascript) have been created for novices, instead of for developers. However, even novices can't read the W3c specs, so it doesn't really help anybody.

</comment><comment><USER37> I deploy the basics of the app as a debian package. Debian is very good at dropping the files and folders where they belong.

There is also a very usable "postinst" installer shell script that can do additional fixups. It can handle things like "if we are on openvz do this, otherwise do that" or "if this is debian 7 (wheezy) fix this; if it is debian 8 (jessie) fix that".

If that is still not enough -- which it sometimes isn't for really complex platforms -- I write an additional shell script that will do the remainder of the work.

But then again, that probably means that the image will have too many moving parts anyway. That means it is time to split the image and stuff a network protocol between the parts. You can use virtual machines for that. The front- end goes left, the back-end right, and other things go top and bottom. Now we are back to more simple images to install and to test.

<comment><USER35> Where did you learn how to build .deb files? Every time I try it ends up being horribly complex and I either go back to a shell script or something like OpenSuse Build Service. Docker is great - when it works, but there's something very wrong with deploying a whole new OS just because we can't work out packaging and deployment properly.

<comment><USER38> Jumping in here, but I always suggest just packaging something pretty vanilla outside of a web app due to all the aforementioned specifics and impedence mismatches of deploying web apps.

Learning some of the innards of the package management system of your machines is surely a good idea in itself, if only because you are relying on them so much. Even if you just say "screw it" and use shell scripts to deploy anyway.

</comment></comment></comment><comment><USER39> My experience installing Discource was a breeze (aws instance, using external postgres and redis servers). This included setting up a custom auth endpoint in my app to allow federated login. I'm amazed that so much effort was made to simplify this process given that their business model revolves around hosting.

</comment><comment><USER40> Yeah everyone up in arm at maven complexity but then you start to use things built by others and suddenly 'if only there was a better way'

There is, but the influx of hacker types into what's an engineering discipline just reset what the field collectively knew to do (when was autoconf introduced again?).

<comment><USER35> I agree. I've made an effort over the past little while to learn Makefiles (after tinkering with waf, ninja, etc) and they can be really good if used properly.

Hell, even Docker can work well if used properly. The secret here is to keep your development machine clean and standardised - this is what Vagrant is for, right?

</comment></comment><comment><USER41> This article badly wants a thing that already exists -- sandstorm.io.

Done.

<comment><USER42> Wow, this is a prime example of a web site not explaining what the hell the software really does.

"Sandstorm is an open source platform for personal servers."

What is it?

<comment><USER43> I'm a web developer, but I can't really use my skills to provide an open source web _app_ the way I'd like to. I'd like to build a small server-side budgeting app that people can use from their computers or phones to record expenses, but there's no way I can ask people to find a web host that lets them run rails, or set up a heroku account or whatever.

So my only alternative would be to run the service _myself_ , but then I'm storing other people's data, I have to worry about scaling if lots of people use it, and user accounts, and all this stuff.

The idea of sandstorm is folks run this platform on their personal servers, and then it lets you browse an app store like interface and one-click install these server side apps. So I'd bundle up my budgeting rails app as a sandstorm package, and if someone wants to track their expenses from a variety of devices, they install the app. Now they're running it so the data is theirs, there's no scaling issues, and user authentication is provided by sandstorm.

Sandstorm is still in its infancy so there's not a lot of apps available and the development APIs are being worked on, but I hope it's the future. It would lead to a more decentralized web with better privacy and users owning their own data.

I'm hopeful, if not optimistic, for a future where every family is expected to have their own little server running somewhere. And they access that server through the sandstorm web interface, and can easily add little apps to it. My budgeting app, a webmail app, some future federated profile app to replace facebook, etc.

<comment><USER42> You know, a picture might really explain it better. If it's something that sits on top of Linux and manages software installation, it's easy to illustrate.

</comment></comment></comment></comment><comment><USER44> A dev learns that deploying apps is hard, wonders why no one solved this already, suggests writing more code will fix the problem.

<comment><USER7> Actually I suggest writing _less_ code, assuming that Docker is a whole lot of code and "what if we write down dependencies" is more interface than code.

<comment><USER44> Your hypothetical vision of the future sounded like you were suggesting writing a tool/system to manage the complexity of dependencies/deployment. I'd recommend changing the thing-to-be-deployed-itself, so it was simpler and had fewer dependencies (if we're talking hypothetical code changes).

Aside: complex software is hard to deploy because it's complex. Software gets complex because devs are very comfortable managing large amounts of complexity. Docker lets you hide that complexity so someone other than the dev can do the build/test/deploy steps, but it does nothing to address the high level of complexity in the underlying software. Let's not mince words here: Discouse is hard to deploy because Rails wasn't designed to make its projects easy to deploy by someone other than the devs primarily working on it, and no amount of tooling around it will change that.

</comment></comment></comment><comment><USER45> What I think is kinda odd about this rant, and about half of the comments here, is the implicit assumption that web forum software must be simple and dumb. "How could it possibly need X, it's just a forum dammit!" Why? Says who? Do we have some "shit's easy" syndrome going on here?

Meanwhile, the users of the forum that I've seen, mostly at TDWTF, seem to mostly complain how short of features and functionality it is/was compared to other BBS solutions.

So which is it? Is it too complex, or not complex enough? It seems to be doing all right at the current level of complexity. If you're suggesting a different one, what makes you think that would be better? Better for who, exactly?

Also note that Discourse is trying to take business from a pile of well- established competitors. To do that, you generally have to be not just as good, but much better, and with flashier features too, for both the users and the mods and admins.

<comment><USER46> People at TDWTF don't complain about Discourse lacking features, they complain about it being overwhelmingly full of bugs and brain-dead behaviors.

Particularly the mobile experience, which is supposed to be one of those things Discourse was designed to do well.

</comment></comment><comment><USER47> Did you know that in asp.net one can deploy apps with just xcopy? I mean this is what the whole rant is all about, right?

<comment><USER10> But you can't mandate a particular version of .Net, or configure SQL with SQL Reporting, or configure add-on services, or request or enumerate firewall rules, with just xcopy.

Which is what the whole rant is about.

<comment><USER47> The rant is about basic web apps like a web forum in his case. your sample about .net version is a no-brainer in shared hosting and sql reporting is not for basic apps.

</comment></comment></comment><comment><USER48> I feel like the real problem here is with the vendor. Had they produced and tested their product against and packaged it for Ubuntu 14 (which is a very common distribution), the user would have had a good experience.

Demanding your users manually install prerequisite software -- especially dependencies that are already included with their OS distribution, and when it's not clear that it's necessary -- is not good practice. And if newer versions of such software are needed, that's what "vendoring" is for: you package all the dependencies along with the software. Sure, it means you might have a duplicate copy of Postgres or whatever, but at least it works out of the box.

</comment><comment><USER49> Maven is fantastic at handling this complexity. It's a pain to initially configure, but once you have it set up you can pretty much forget about it. Similar to the author, my experiences with Gem and Bundler have been rather painful due to a combination of things like Cygwin/Windows issues, incompatibilities between Ruby versions, and 32/64 bit problems. Maven isn't quite perfect, I'd really like the ability for dependencies to have their sub- dependencies sandboxed in their own namespaces, I've run into some weird quirks with load order and the API-only JavaEE packages, but once you get a POM written it's totally reliable.

I bitch just as much as the next guy about the mistakes that have long since been baked into the Java environment, but that dedication to backwards compatibility does pay off. Similarly, the fact that it's running on a JVM rather than bare metal has its performance costs, but it does allow you to trust that the actual computation will Just Work wherever you run it (although of course the stuff that touches the surrounding environment will not).

In the comments the author states that he wants something "less invasive" than Docker. I'm not sure what that actually means - for me, having to actually install it and deal with the versioning on my real system is more invasive. Containerized applications that build their own runtime environments is a step in the right direction there, just like the JVM. Docker has some really dumb defaults right now, running as root has been known to be retarded since forever and you should not encourage users to do it. But running as root is problematic for lots of other reasons, and causes the potential for jailbreak on other jails too (eg chroot). FreeBSD jails seem to have some good rules on what you're allowed to do inside a jail.

If you really want "minimal invasiveness" and your software really really requires that you have superuser privileges then you should probably be running a full-fat VM with an OS inside, with the network sandboxing happening at the host. Even then, it's not like even Xen hasn't had the occasional jailbreak. The real problem is that the program itself should never require running as root in the first place - but that's a problem with Discourse, not a problem with jails.

</comment><comment><USER50> Here's how I deploy:

        cf push

It requires zero configuration on my part.

Actually, I'm lying. Here's how I deploy:

        git push

CI then verifies my work before running this arcane command:

        cf push

It took literally minutes to set up. It'd be nice if it was psychic but I guess I'll just have to settle for an imperfect world.

</comment><comment><USER51> Or you could have just installed a Bitnami image until you're willing to jump through all the hoops necessary to get many multiple moving pieces to work together happily.

Ops is hard dude. Sorry about that.

[https://wiki.bitnami.com/Applications/BitNami_Discourse](https://wiki.bitnami.com/Applications/BitNami_Discourse)

</comment><comment><USER52> I find it interesting that no one has mentioned [http://nixos.org](http://nixos.org) even here on HN...

Isn't it suppose to address most of those grieves the author was complaining about (and I have also experienced so I have up on Ruby years ago and did some nodejs but that's not really different either)?

</comment><comment><USER53> We are trying to solve this problem with Flockport [1] so users can at least get to see and try apps without needing to install and configure tons of stuff and we use LXC containers which behave like lightweight VMs and provide an OS environment similar to a VM or a bare metal server that users are more familiar with. And this also allows us to package the stack and app in a single container..

With Docker apart from the app you have to deal with the additional complexity of a single app environment that is not an environment that most users are familiar with, for instance you need to launch all your apps in 'non daemon mode' (how many uses know how to do this, and why you would need it?) figure out how to deal with storage persistence, networking and 'linking containers' and things like logging, cron and ssh (there is no place for these in single app containers). Installing something as simple as Mysql with Docker is non trivial because of storage. So this adds a whole new layer of complexity on top of the app that's makes it completely unsuitable to package apps if simplicity and accessibility is the objective. You need to be a real expert to deal with this, much more than LXC containers or VMs.

We have a guide on building a simple Wordpress stack from scratch with Docker [2] that gives readers an understanding of the level of complexity involved with Docker and what it seems to be designed for. It's not for end users and certainty not to making things simple. It would take a tenth of the effort to install Wordpress in a VM or LXC container. But its pointless to compare VMs or LXC containers to Docker, as Docker is intended for a completely different use case and that's what its users and advocates should highlight and push.

We have packaged over 60 apps in LXC containers at Flockport and Ruby apps are by far the most complex to setup, usually requiring a complete build environment. PHP is the simplest both to install and troubleshoot, and usually just works. The Ruby apps like Redmine, Gitlab are more complex and Discourse is the toughest to get going. You need to be an expert to install it and an even bigger expert to run it so much so that I think unless you are a rails developer the only reliable way to use Discourse is to have the Discourse team manage it.

[1] [https://www.flockport.com](https://www.flockport.com)

[2] [https://www.flockport.com/a-beginners-guide-to- docker](https://www.flockport.com/a-beginners-guide-to-docker)

</comment><comment><USER54> Corrected title: the sad state of one developer's experience with one web app deployment.

</comment><comment><USER55> I think that the vast majority of web apps could be deployed via shell script that calls out commands to the particular system. I'm not too optimistic about Docker since it is vastly more complex than the alternative (VM + shell).

</comment><comment><USER56> If a web app is huge, it should have a plugin system. So you only need to get a basic configuration for basic features (without complicated monitoring, full text search).

Then you install more, configure more if you want something more advanced.

</comment><comment><USER57> A lot of people are criticizing the author but I know much less about installing things on Linux and quite quickly managed to install another, more conventional forum without any of the problems he mentioned. I just copied the files into a folder, created a database, ran an install script (not as root) and everything worked. Still not ideal but much easier. Why should installing software require some kind of expert? Why didn't the developers solve that problem themselves so every user can just use it easily. This isn't limited to web apps, it's most open source software. The authors don't put effort into making it easy even though they're the ones who are best positioned to both understand it and provide the greatest benefit by saving everybody else from repeating the same struggle.

<comment><USER11> From the developers' INSTALL file:

 _" Hosting Rails applications is complicated. Even if you already have Postgres, Redis and Ruby installed on your server, you still need to worry about running and monitoring your Sidekiq and Rails processes. Additionally, our Docker install comes bundled with a web-based GUI that makes upgrading to new versions of Discourse as easy as clicking a button."_

The basic install guide is a bit lengthy, but amounts to writing these commands:

      ssh email@example.com
      wget -qO- https://get.docker.com/ | sh
      mkdir /var/discourse
      git clone https://github.com/discourse/discourse_docker.git /var/discourse
      cd /var/discourse
      cp samples/standalone.yml containers/app.yml
      nano containers/app.yml
      ./launcher bootstrap app
      ./launcher start app

There's definitely some extra configuration that has to take place between these steps, but it seems to me that they've gone through a lot of trouble to make it easy for their users. I'm not sure where you're getting the idea that it requires an expert to install Discourse -- it only requires one when you have a _very_ unconventional build toolchain on your Linux box and refuse to use Docker (the officially supported deployment method).

<comment><USER57> OK, I understand now.

</comment></comment></comment><comment><USER58> Ok I'll bite. This is a good reason to use PHP. In fact, I first learned PHP because I had a specific web application I wanted to write that needed to be dead simple for relatively tech phobic users to deploy, and PHP won.

For small things it works well and I've never had a single installation as painful as any of the stuff described in this article. For big things, well there's Facebook. It may be ugly, but it's definitely doable.

It's not the new shiny, it's full of warts, and it's unfashionable. (If you tell a fellow programmer you code in PHP you immediately need to rebuild credibility somehow.) I personally prefer working with JavaScript and nodejs but I don't think the deployment situation for nodejs is much better/different from what's described here.

<comment><USER59> Thinking these high level problems can be solved by switching to a different language is quite a common fallacy in the tech world. Almost always it comes down to being familiar with the platform/OS/languages you're working with rather than a few attributes of a particular technology choice. The question of technology choice in that context is then primarily about using something with reasonable popularity and an adequete community supporting it - <USER2> usually not much more than that.

</comment></comment><comment><USER60> Nix and NixOS as a whole solve this entire problem in a really nice way. Its still not ready for prime time from my personal experience, but the ideas and foundation are there... just needs more polishing.

</comment><comment><USER61> Another title: Coding Sucks: Why a Job in Programming Is Absolute Hell

</comment><comment><USER62> Side note: LD_LIBRARY_PATH is bad, do not use it. Among other things it will crash your 64 bit app if 32 bit lib matches by name (or vice versa). Bad, bad, bad. Use ld and ldconfig.

</comment><comment><USER63> I think we've all felt like this before.

Is this one of the reasons people use Java? Is it way wrong to say Docker is like a JVM for non-Java?

</comment><comment><USER64> Haha, Docker. Few months ago that word started being peppered throughout conversations in the office, everybody keen to jump on the bandwagon. Guess what, now we hired a "docker expert".

If this thing is so simple a toothless toddler could use it, how come now we need experts in it, huh?

</comment><comment><USER65> What rhymes with 'piss horse'? I'm really curious now.

<comment><USER66> Discourse?

</comment></comment><comment><USER67> This is a story of somebody not really knowing what he does.

</comment><comment><USER68> I quite like Node BB...

</comment><comment><USER69> I think Discourse is an over-engineered catastrophe, a prime example of highly-skilled technical people unable to make business decisions. As the author says, this a web-forum software, all it is doing is displaying some text on a page and maybe sending an email. This was a solved problem 15 years ago with PHP. But they wanted to re-implement everything in a technically- purist manner, and end up with the absurd situation where you need to install a virtual container to perform one of the most basic computing functions there is: displaying text on a page. And that's just the server-side, the client rendering is so over-engineered that it only works on the very latest browsers. TO DISPLAY TEXT! Completely bonkers. They needed a "user-experience evangelist" or whatever you call them on that team.

<comment><USER70> > As the author says, this a web-forum software, all it is doing is displaying > some text on a page and maybe sending an email. This was a solved problem 15 > years ago with PHP

This reminds me of what Jeff Atwood had to say about people over simplifying the nature of stack overflow (and by extension, claiming it to be over valued).

He eventually responded about the fact that the little details mattered. From auto searching for existing similar questions to little prompts on framing the question.

Similarly, Discourse is being built with principles in mind that go beyond a threaded discussion. It's attempting to answer the question of "can we use software to encourage a civilized discourse?". It's easy to ignore this, and look at it as bloated. But in that vein, Stack overflow is a bloated Yahoo answers or any other. And we all know it isn't. Essentially, it's more than just "a web-forum software". That distinction really matters.

Relevant links:

1: [http://blog.codinghorror.com/this-is-all-your-app-is-a- colle...](http://blog.codinghorror.com/this-is-all-your-app-is-a-collection- of-tiny-details/) 2: [http://blog.codinghorror.com/code-its- trivial/](http://blog.codinghorror.com/code-its-trivial/) 3: [https://news.ycombinator.com/item?id=678501](https://news.ycombinator.com/item?id=678501)

<comment><USER11> > "can we use software to encourage a civilized discourse?"

After carpet bombing this thread with my own criticism, this was a good reminder of why that was probably stupid. Thanks :).

</comment></comment></comment><comment><USER71> The author seems to mistakenly believe that Linux is a multi-user system where not everyone has root privileges.

The reality is that almost nobody uses it that way, it's not tested for that and due to the huge API surface area the chance of some kind of exploit is so large that it cannot be secured even if it people tried.

The only reason "root" exists currently is to make it less likely to accidentally change or destroy the operating system.

There is no way to provide a multi-user experience on a physically accessible system (cannot defend against physical attacks), and the way to provide it on a remotely accessible system is to assign a virtual machine to each user.</comment>


The Secret to Designing the Right Product - <AUTHOR> https://medium.com/product-design/70e9a4839adf/

<comment><AUTHOR> Let me know if you have other thoughts or disagree!</comment>


Is SEO Dead? - <AUTHOR> https://seocompetitoranalysis.com/seo-dead <comment><AUTHOR> In fact, answering the question about SEO's death, every SEO specialist should ask in return: "What are you waiting for from SEO?", "Do you know and understand the SEO competitiveness in your niche", "How much are you ready to invest in long-term SEO startegy" and "How long are you ready to wait for the first results?".</comment>


China's first 'cyber-dissident' jailed for 12 years - <AUTHOR> https://www.theguardian.com/world/2019/jul/29/china-first-cyber-dissident-huang-qi-jailed-12-years <comment><USER2> Anyone know where to find a mirror or archive of this?

Would want to host this..</comment>


Earth barreling toward 'Hothouse' state not seen in 50M years - <AUTHOR> https://www.livescience.com/oldest-climate-record-ever-cenozoic-era.html <comment> radford-neal An quote from the article:

        This event, known as the Paleocene-Eocene Thermal Maximum,
        saw temperatures up to 60 degrees Fahrenheit (16 degrees Celsius)
        above modern levels

I think one cannot assume that anything in this article is correct.

<comment><USER2> The original paper presumably does not have such errors; these most likely come from the journalist trying to be helpful and translate celsius into fahrenheit. An increase of 16 degrees C is of course 28.8 degrees fahrenheit.

<comment><USER3> I'm confused, why is this the case?

<comment><USER4> Because they don't have the same zero point. 16 deg Celsius on the thermometer is 60.8 deg Fahrenheit, but if you're measuring difference, you have to do 16 - 0 C = 60.8 - 32 F = 28.8 F. Or to make it clear, 16 going to 32 C is 60.8 F going to 89.6 F, also a difference of 28.8 F.

Or just do 16/5*9 without adding 32, so you'd get 28.8 F.

<comment><USER3> Ah, silly me. Thanks!

</comment></comment></comment></comment></comment><comment><USER5> [https://www.bbc.co.uk/programmes/b08hpmmf](https://www.bbc.co.uk/programmes/b08hpmmf) is an interesting and accurate discussion of the Paleocene-Eocene Thermal Maximum.

</comment><comment><USER6> The sky is falling soon...promise.</comment>


Best bookmarking tool? Delicious just lost 1500+ of my bookmarks - <AUTHOR>

<comment><USER2> I use Pocket ( [http://getpocket.com](http://getpocket.com) ) with IFTTT ( [http://ifttt.com](http://ifttt.com) ) copying them to Pinboard ( [http://pinboard.in](http://pinboard.in) ), Instapaper ( [http://instapaper.com](http://instapaper.com) ), and also appended to a text file in Dropbox.

</comment><comment><USER3> Evernote. [https://evernote.com/webclipper/](https://evernote.com/webclipper/)

</comment><comment><USER4> Pocket is a very useful tool: [http://getpocket.com/](http://getpocket.com/)</comment>


Notes on Superhuman's Acquisition Loops - <AUTHOR> https://kwokchain.com/2019/10/24/notes-on-superhumans-acquisition-loops/ <comment><USER2> Superhuman has been invite only for years, apparently to be able to choose their users and grow via word of mouth. Respectfully, why is a supposedly fast amazing email experience worth paying for? I might've missed something...

<comment><USER3> It's not worth paying for.

VCs and other high-ego executives use this purely as a status symbol.

</comment></comment><comment><USER4> Pretty much the same mechanism as gmail beta hype, but this costs $30 a month.

</comment><comment><USER5> The founder of Superhuman was just on This Week in Startups and discussed their process for driving product/market fit - [https://overcast.fm/+JyGzBXWg/3:25](https://overcast.fm/+JyGzBXWg/3:25)</comment>


The fundamental problem of programming language package management - <AUTHOR> http://blog.ezyang.com/2014/08/the-fundamental-problem-of-programming-language-package-management/ <comment><USER2> Nix, NixOS, Nix ... a thousand times Nix.

I can't believe the article doesn't mention it.

I've been using NixOS as my OS for development, desktop and we're in the middle of transitioning to using it for production deployments too.

Nix (the package manager not the distribution) solves so many of the discussed problems. And NixOS (the linux distribution) ties it all together so cleanly.

I keep my own fork of the Nixpkgs repository (which includes everything required to build the entire OS and every package), this is like having your own personal linux distribution with the but with the simplest possible way of merging changes or contributing from upstream.

I use it like I'd use virtualenv. I use it like I'd use chef. I use it like I'd use apt. I use it like I'd use Docker.

[http://www.nixos.org](http://www.nixos.org)

<comment><USER3> Yes! The Haskell community has been using Nix to great effect and I would like to see other programmers catch on as well. Here is a great talk about using Nix targeted at Python programmers: [http://pyvideo.org/video/3036/rethinking- packaging-developme...](http://pyvideo.org/video/3036/rethinking-packaging- development-and-deployment)

In addition to Nix, there is also a newer project: GNU Guix. Guix is built on top of Nix but replaces the custom package configuration language with Scheme, among other differences. [https://gnu.org/software/guix/](https://gnu.org/software/guix/)

When package management is solved at the system level, our deployment situation becomes a whole lot better. I used to do a lot of Ruby programming. Wrestling with RVM and bundler was a real pain, especially since bundler was incapable of helping me with the non-Ruby software that I needed as well like libmysqlclient, imagemagick, etc. Using Nix/Guix, you can throw out hacky RVM (that overrides bash built-ins like cd!) and simply use a profile that has the right Ruby version.

Bye pip, bundler, composer, CPAN, puppet, ansible, vagrant, ..., and hello Nix/Guix!

<comment><USER4> You could of course use a platform that doesn't depend on OS dependent binaries (like the JVM) and a package manager that likes ad-hoc and easily created repositories and that has lots of plugins available (Maven, or derivates like Gradle, SBT or Leiningen).

I worked with a lot of platforms, such as PHP, Perl, Ruby, Python, Node.js and .NET. I felt the pain of pip, easy_install, setup-tools, virtualenv, bundler, gems, cpan, pear, rvm, rbenv, npm, bower, apt-get or whatever else I used at some point or another. And I swear, in spite of all the criticism that Java or Maven get and in spite of all warts, in terms of packaging and deployment for me it's been by far the sanest. I mean, it's not without warts, heaven forbid to end up with classpath issues due to transitive dependencies, but at the very least it is tolerable.

<comment><USER3> >You could of course use a platform that doesn't depend on OS dependent binaries (like the JVM) and a package manager that likes ad-hoc and easily created repositories and that has lots of plugins available (Maven, or derivates like Gradle, SBT or Leiningen).

I don't think being locked into the JVM is a very good solution. Java libraries can depend on other non-Java components.

</comment></comment></comment></comment><comment><USER5> This topic reminded me of some very interesting thoughts from Joe Armstrong, that I remember seeing posted somewhere (HN?) some time ago -- "Why do we need modules at all?":

        [...]
        The basic idea is

            - do away with modules
            - all functions have unique distinct names
            - all functions have (lots of) meta data
            - all functions go into a global (searchable) Key-value database
            - we need letrec
            - contribution to open source can be as simple as
              contributing a single function
            - there are no "open source projects" - only "the open source
              Key-Value database of all functions"
            - Content is peer reviewed

        These are discussed in no particular order below:
        [...]

Full thread: [http://thread.gmane.org/gmane.comp.lang.erlang.general/53472](http://thread.gmane.org/gmane.comp.lang.erlang.general/53472)

<comment><USER6> > \- all functions have unique distinct names

Seriously? Is that his solution to package management?

<comment><USER7> Well, if you're using packages and modules, the full name of your function is still packagename/modulename::functionname; it might as well be packagename.modulename.functionname.

Keep in mind that Joe Armstrong is talking about Erlang here, which is a functional language - most of the functions in libraries are sort-of kind-of independent from each other; they especially don't share state.

</comment></comment></comment><comment><USER8> When I sit around and think "what's the biggest improvement I could make personally to the computing world?" there's always this voice in my head saying "kidnap whoever is building the next package management system and lock them in a deep dark box."

There seems this fundamental disconnect between people _making_ languages about how people _use_ their languages. I don't have time to follow your Twitter feed, because I'm working on a lot of different things. I know it's important _to you_ , the Language Developer, and so you think it should be important _to me_ , the Language User. But I have dozens of things to keep track of, and all of them imagine that they're the most important thing in my world.

It's like the old office culture mocked in "Office Space" where the guy has 7 different bosses, each imagining their own kingdom is the most important.

</comment><comment><USER9> Completely misses the real fundamental problem: people make assumptions about their target. Almost all of this discussion is centered around Linux systems. What about Windows? What about Solaris? HPUX? AIX? VMS? Tru64? Plan9? BeOS? Android?

Package management itself is not a solved problem, so you can't very well expect programming languages to be any different. The existing systems work quite well and make total sense: your package manager is tailored to your specific use case. Centralized/decentralized is a red herring. First figure out how to package every single thing for every single system and use case in the world, and then come back to me about organizational systems.

<comment><USER10> Agree completely. The fundamental problem of package management is _the dependencies of the package manager itself_.

Every programming language has its own package manager because _it 's written in that language_. No language maintainer is going to say something like, "Hey, want to use Ruby? Just install Perl first so you can install some Ruby packages!"

Likewise, every OS-level package manager assumes an OS. I'm sure apt-get, and yum and Nix are great. I'm also sure their greatness isn't very helpful to Windows users.

There's also the dependency between those two. An OS-level package manager can't easily be written in a high-level language, because one of its core jobs is _to install high level languages_. A language-level package manager doesn't want to re-invent the OS stack.

Bootstrapping is hard. Package managers sit very very low on the software stack where _any_ dependencies are very difficult to manage and where consolidation is nigh impossible.

</comment></comment><comment><USER11> The downside he mentions to "pinned versions" actually applies to everything on this page. If you don't pay attention to security updates, you will be vulnerable whether or you forgot about your pinned versions or you forgot about your stable distribution.

"Stable" distributions have an additional downside he doesn't mention: when you upgrade every package all at once it's a LOT more effort than if you had upgraded them slowly over time. Dealing with multiple library changes at once is an order of magnitude more difficult than dealing with them one-at-a-time.

And also, to some extent, if all the libraries you are using have a long term stable API, then it doesn't actually matter which one you pick - anything is painless.

<comment><USER12> > Dealing with multiple library changes at once is an order of magnitude more > difficult than dealing with them one-at-a-time.

Curious... I have exactly the opposite experience. I find that a certain amount of time is required to carefully regression-test my application code after upgrading a library. Doing this 23 times for my 23 different dependencies that need to be upgraded can be quite costly. If I, instead, upgrade all of the libraries at once and perform my extensive regression testing just once, I save a great deal of effort.

That's if everything goes smoothly. If something does NOT go smoothly and I encounter an error, then I need to determine which upgrade caused the problem. Most of the time (85% perhaps?), that turns out to be easy and obvious just by looking at the error that presents itself. In the remaining cases, I simply roll back half of the package upgrades and start binary-searching to identify the culprit (or culprits in the case of a conflict between libraries).

<comment><USER11> Do you have an automated testing suite? That might explain the difference in experience. I use a lot of automated tests

<comment><USER13> I don't think its the testing thats work intensive, its fixing things that broke. The more often you upgrade the more often things will break.

<comment><USER11> Maybe, but s/he did explicitly mention the regression testing taking a long time

</comment></comment></comment></comment></comment><comment><USER14> Every program with plugins of any sort will eventually include a sketchy rewrite of apt-get. Not just languages - WordPress, MediaWiki ...

If you're _very_ lucky, the packaging in question will not conflict horribly with apt or yum. So you probably won't be lucky.

<comment><USER4> As if apt-get would solve the problems that we have. Good luck in installing multiple versions of the same package with apt-get.

<comment><USER15> Inability to install multiple versions of the same package can be a feature. It encourages the creation of stable, backwards-compatible packages.

<comment><USER4> Sure, it kind of makes sense for managing the software repository of your operating system. But when doing software development, you end up with multiple projects using multiple versions of the same dependency. I mean I tried going the apt-get route back when I was working with Perl - a lot of people in the Perl community like apt-get and there are tools for easily packaging a library into a deb, but it was a pain working on or deploying multiple projects on the same machine.

<comment><USER15> > But when doing software development, you end up with multiple projects using > multiple versions of the same dependency.

That's what I wish the language designers had avoided. It would be convenient for users if there were never any reasons to want anything but the most recent version.

I know Perl and similar languages tend to value rapid development over complete reliability, but I'd prefer not to think about version numbers or worry about updates that break things. Maybe if the package management systems had been designed with less rope, users would more rarely get hung.

</comment></comment></comment></comment></comment><comment><USER16> yeah yeah, I read the previous post ([http://www.standalone- sysadmin.com/blog/2014/03/just-what-we...](http://www.standalone- sysadmin.com/blog/2014/03/just-what-we-need-another-package-manager/)) too.

Maybe this time we can talk about how to meaningfully solve these problems instead of just fighting pointlessly about if old tools are so great should be used for everything.

Decentralized package management huh?

How would that work?

A way of specifying an ABI for a packages instead of a version number? A way to bundle all your dependencies into a local package to depend on and push changes from that dependency tree automatically to builds off of it, but only manually update the dependency list?

I'm all for it. Someone go build one.

<comment><USER17> > A way of specifying an ABI for a packages instead of a version number?

Technically impossible for many languages (have fun figuring out what it would look like in Perl...). And even when it's possible, it's not a guarantee: you can have a semantic change without an ABI change. Cargo, Rust's newfangled package manager, supposes semantic versioning, and I think it's a sane attitude.

<comment><USER18> Stronger and stronger typing makes this ABI guarantee stronger and stronger. Dependent typing could package theorems about the properties of your interface and then ensure that all matches satisfy those properties. You'd like depend upon their theorems to prove things about your own program knowing that nothing can break.

<comment><USER17> Yes, but something like Idris isn't mainstream. 99% of the languages out there don't allow you to express this kind of invariant.

<comment><USER18> Certainly, but it's going to become more and more so. The right way to do an API is to expose your invariants. Some day that will be a thing—and the distributed problem will still be here.

<comment><USER17> That or we will all have to write Javascript in Javascript :)

</comment></comment></comment></comment></comment></comment><comment><USER19> Just by reading the title I expected this would be about fixing the dependency diamond problem. I.e. when library A needs library C 1.0 and B needs library C 1.1 incompatible with C 1.0 and then libraries A and B meet in the same project :(

<comment><USER20> In Java-land, OSGi was invented to solve this very problem. Every module has its own classloader so module A can load C 1.0 and module B can load C 1.1. Modules are registered and other modules can look them up in the registry and call them so A can look up and then call B without conflicts.

<comment><USER21> OSGi is good in theory but too much ado for most real-world projects.

<comment><USER20> Agreed. The Spring support helps a lot though. But there's no question that OSGi is one of the final big xml holdouts in Java-land.

</comment></comment></comment></comment><comment><USER22> Even reducing the problem to one language you run into problems. All serious R developers have run into issues with CRAN (which is mostly centralized) causing problems with different version installs using install.package(). There are mechanisms for dealing with it, but the best solution is usually to maintain your own distribution of packages and a build script: further centralization. And R has a relatively good/simple package management system compared to something like pip, luarocks or Maven. Two which I never had problems with ... maybe because I didn't use them enough: leiningen and go get.

</comment><comment><USER23> > The Git of package management doesn't exist yet

We've taken a pretty good shot at this in the OCaml ecosystem the via OPAM package manager ([https://opam.ocaml.org](https://opam.ocaml.org)).

* OPAM composes its package universe from a collection of remotes, which can be fetched either via HTTP(S), Git, Hg or Darcs. The resulting package sets are combined locally into one view, but can be separated easily. For instance, getting a view into the latest XenAPI development trees just requires "opam remote add xapi-dev git://github.com/xapi-project/opam-repo-dev".

* The same feature applies to pinning packages ("opam pin add cohttp git://github.com/avsm/ocaml-cohttp#v0.6"). This supports local trees and remote Git/Hg/Darcs remotes (including branches).

* OCaml, like Haskell, is statically typed, and so recompiles all the upstream dependencies of a package once its updated. This lets me work on core OCaml libraries that are widely used, and just do an "opam update -u" to recompile all dependencies to check for any upstream breakage. We did _not_ go for the very pure NixOS model due to the amount of time it takes to compile distinct packages everywhere. This is a design choice to balance composability vs responsiveness, and Nix or 0install are fine choices if you want truely isolated namespaces.

* By far the most important feature in OPAM is the package solver core, which resolves version constraints into a sensible user-facing solution. Rather than reinvent the (rather NP-hard) solver from scratch, OPAM provides a built-in simple version and also a CUDF-compatible interface to plug into external tools like aspcud, which are used by other huge repositories such as Debian to handle their constraints.

This use of CUDF leads to some cool knobs and utilities, such as the OPAM weather service to test for coinstallability conflicts: [http://ows.irill.org/](http://ows.irill.org/) and the solver preferences that provide apt-like preferences: [https://opam.ocaml.org/doc/Specifying_Solver_Preferences.htm...](https://opam.ocaml.org/doc/Specifying_Solver_Preferences.html)

* Testing in a decentralized system is really, really easy by using Git as a workflow engine. We use Travis to test all incoming pull requests to OPAM, much like Homebrew does, and can also grab a snapshot of a bunch of remotes and do bulk builds, whose logs are then pushed into a GitHub repo for further analysis: [https://github.com/ocaml/opam-bulk-logs](https://github.com/ocaml/opam-bulk-logs) (we install external dependencies for bulk builds by using Docker for Linux, and Xen for *BSD: [https://github.com/avsm/docker-opam](https://github.com/avsm/docker-opam)).

All in all, I'm very pleased with how OPAM is coming along. We use it extensively for the Mirage OS unikernel that's written in OCaml (after all, it makes sense for a library operating system to demand top-notch package management).

If anyone's curious and wants to give OPAM a spin, we'd love feedback on the 1.2beta that's due out in a couple of weeks: [http://opam.ocaml.org/blog/opam-1-2-0-beta4/](http://opam.ocaml.org/blog/opam-1-2-0-beta4/)

<comment><USER24> I am a Haskell programmer who got to use OPAM when installing Coq (HoTT version) recently. It was surprisingly nice.

Also, you can pick which version of the compiler to run, and have it manage switching everything.

It seemed like it was years ahead of cabal, but that might just be because I only used it a little, I don't know. But there are some things to learn from OPAM.

Do you have a blog post like this, or something I could post the the Haskell subreddit?

<comment><USER23> We're planning a post after the ICFP rush next week dies down, but there's a rather specific one on the new pinning workflow in OPAM 1.2 here:

[http://opam.ocaml.org/blog/opam-1-2-pin/](http://opam.ocaml.org/blog/opam-1-2-pin/)

(How to pin a development is central to the day-to-day development workflow of OCaml/OPAM users and quite annoying to change after-the-fact, so we're eager for feedback on this iteration before we bake it into the 1.2.0 release).

The OPAM blog is only about 2 weeks old, so there'll are quite a few more posts coming up as our developers discover there's quite a lot to write about :)

<comment><USER24> (It looks like your rss feed is broken somehow. If I subscribe, and then try and view your site I get about:blanks, at least in InoReader. But I can view it in the reader fine.)

I'm quite excited.

</comment></comment></comment></comment><comment><USER25> Apache Ivy is built on Java and could be a starting point for the uber package manager. It is extremely extensible and can resolve depencies against maven style repos, file systems, and really any other storage mechanism. It can resolve against multiple repos simultaneously.

The real problem is that its so powerful and hard to ramp up on... The docs aren't sufficient for its overall complexity. That all aside, if the will were there, it could be the git of package managers.

</comment><comment><USER26> From a dumb-user perspective, I feel like most of the effort of package managers is spent on resolving these fundamentally incompatable philosophical dilemmas instead of common-denominator solvable problems like:

* Quality and Trust mechanisms. If there are 14 different postgres clients, which do I choose?

* Package Metadata management. Where can I send bug reports? Who is the maintainer? How can I contact someone? Is there an IRC channel?

* Documentation and Function/Class Metadata. Why should I go to the Github README for one package, and to a random domain for another package?

* Linking compile and runtime error messages to documentation or bug reports. Why is google still the best way to track down the cause of an obscure error message?

* Source data linking and code reviews. I should be able to type in a module/namespace qualified function name and view the source without having to scour a git repository. I should also be able to comment directly on that source in a way that is publicly visible or privately visible.

</comment><comment><USER27> The situation with packages and dependency hell today is horrendous, particularly if you work in a highly dynamic environment like web development.

I want to illustrate this with a detailed example of something I did just the other day, when I set up the structure for a new single page web application. Bear with me, this is leading up to the point at the end of this post.

To build the front-end, I wanted to use these four tools:

\- jQuery (a JavaScript library)

\- Knockout (another JavaScript library)

\- SASS (a preprocessor to generate CSS)

\- Jasmine (a JavaScript library/test framework)

Notice that each of these directly affects how I write my code. You can install any of them quite happily on its own, with no dependencies on any other tool or library. They are all actively maintained, but if what you've got works and does what you need then generally there is no need to update them to newer versions all the time either. In short, they are excellent tools: they do a useful job so I don't have to reinvent the wheel, and they are stable and dependable.

In contrast, I'm pretty cynical about a lot of the bloated tools and frameworks and dependencies in today's web development industry, but after watching a video[1] by Steven Sanderson (the creator of Knockout) where he set up all kinds of goodies for a large single page application in just a few minutes, I wondered if I was getting left behind and thought I'd force myself to do things the trendy way.

About _five hours_ later, I had installed or reinstalled:

\- 2 programming languages (Node and Ruby)

\- 3 package managers (npm with Node, gem with Ruby, and Bower)

\- 1 scaffolding tool (Yeoman) and various "generator" packages

\- 2 tools that exist only to run other software (Gulp to run the development tasks, Karma to run the test suite) and numerous additional packages for each of these so they know how to interact with everything else

\- 3 _different_ copies of the same library (RequireJS) within my single project's source tree, one installed via npm and two more via Bower, just to use something resembling modular design in JavaScript.

And this lot in turn made some undeclared assumptions about other things that would be installed on my system, such as an entire Microsoft Visual C++ compiler set-up. (Did I mention I'm running on Windows?)

I discovered a number of complete failures along the way. Perhaps the worst was what caused me to completely uninstall my existing copy of Node and npm — which I'd only installed about three months earlier — because the scaffolding tool _whose only purpose is to automate the hassle of installing lots of packages and templates_ completely failed to install numerous packages and templates using my previous version of Node and npm, and npm itself _whose only purpose is to install and update software_ couldn't update _Node and npm themselves_ on a Windows system.

Then I uninstalled and reinstalled Node/npm again, because it turns out that using 64-bit software on a 64-bit Windows system is silly, and using 32-bit Node/npm is much more widely compatible when its packages start borrowing your Visual C++ compiler to rebuild some dependencies for you. Once you've found the correct environment variable to set so it knows which version of VC++ you've actually got, that is.

I have absolutely no idea how this constitutes progress. It's clear that many of these modern tools are only effective/efficient/useful at all on Linux platforms. It's _not_ clear that they would save significant time even then, compared to just downloading the latest release of the tools I actually wanted (there were only four of those, remember, or five if you count one instance of RequireJS).

And here's the big irony of the whole situation. The _only_ useful things these tools actually did, when all was said and done, were:

\- Install a given package within the local directory tree for my project, with certain version constraints.

\- Recursively install any dependent packages the same way.

That's it. There is no more.

The only things we need to solve the current mess are standardised, cross- platform ways to:

\- find authoritative package repostories and determine which packages they offer

\- determine which platforms/operating systems are supported by each package

\- determine the available version(s) of each package on each platform, which versions are compatible for client code, and what the breaking changes are between any given pair of versions

\- indicate the package/version dependencies for a given package on each platform it supports

\- install and update packages, either locally in a particular "virtual world" or (optionally!) globally to provide a default for the whole host system.

This requires each platform/operating system to support the concept of the virtual world, each platform/operating system to have a single package management tool for installing/updating/uninstalling, and each package's project and each package repository to provide information about versions, compatibility and dependencies in a standard format.

As far as I can see, exactly none of this is harder than problems we are already solving numerous different ways. The only difference is that in my ideal world, the people who make the operating systems consider lightweight virtualisation to be a standard feature and provide a corresponding universal package manager as a standard part of the OS user interface, and everyone talks to each other and consolidates/standardises instead of always pushing to be first to reinvent another spoke in one of the wheels.

We built the Internet, the greatest communication and education tool in the history of the human race. Surely we can solve package management.

[1] [http://blog.stevensanderson.com/2014/06/11/architecting- larg...](http://blog.stevensanderson.com/2014/06/11/architecting-large-single- page-applications-with-knockout-js/)

<comment><USER9> Sure we can. I imagine first we'll need the ISO to create a project to begin the standardization of software management. Then there'll probably be a few years of research to identify all the kinds of software, platforms they run on, interoperability issues, levels of interdependencies, release methodologies, configuration & deployment models, maintenance cycles, and expected use cases. Then the ISO can create an overly-complex standard that nobody wants to implement. Finally somebody will decide it's easier to just create smaller package managers for each kind of software and intended use case and write layers of glue to make them work together.

So now that we know what to do, the big question is: who's going to spend the next 5-10 years of their life on that project?

<comment><USER27> _So now that we know what to do, the big question is: who 's going to spend the next 5-10 years of their life on that project?_

But this is my point: We are _already_ solving all of those problems, and doing almost all of the work I suggested.

All of the main package managers recognise versions and dependencies in some form. Of course the model might not be perfect, but within the scope of each set of packages, it is demonstrably useful, because many of us are using it every day.

All of the people contributing packages to centralised package repositories for use with npm and gem and pip and friends are already using version control and they are already adding files to their projects to specify the dependencies for the package manager used to install their project — or in many cases, for multiple package managers, so the project can be installed multiple different ways, which is effectively just duplicated effort for no real benefit.

All major operating systems already come with some form of package management, though to me this is the biggest weak point at the moment. There are varying degrees of openness to third parties, and there is essentially no common ground across platforms except where a few related *nix distributions can use the same package format.

All major operating systems also support virtualisation to varying degrees, though again there is plenty of scope for improvement. I've suggested before that it would be in the interests of those building operating systems to make this kind of isolation routine for other reasons as well. However, even if full virtual machine level isolation if too heavyweight for convenient use today, usually it suffices to install the contents of packages locally within a given location in the file system and to set up any environment accordingly, and again numerous package managers already do these things in their own ways.

There is no need for multi-year ISO standardisation processes, and there is no need to have everything in the universe work the same way. We're talking about tools that walk a simple graph structure, download some files, and put them somewhere on a disk, a process I could have done manually for the project I described before in about 10 minutes. A simple, consolidated version of the best tools we have today would already be sufficient to solve many real world problems, and it would provide a much better foundation for solving any harder problems later, and it would be in the interests of just about everyone to move to such a consolidated, standardised model.

<comment><USER9> The problem you cited before is _supposed_ to be easy, but in practice, software development that uses 3rd-party software is destined to run into conflicts. You found portability issues, platform-dependent issues, environment/configuration issues, and multi-layer software dependency issues.

These all happen regularly when OS maintainers have to package software for release. They spend thousands of hours to resolve [by hand] each one in order to support the various use-cases of their end users. If you are imagining some automated process just magically makes all your software come together to build you a custom development environment, you are mistaken. It's all put together by humans, and only for the use cases that have been necessary so far.

So yes, all these things exist. In small, bespoke, use-case-specific solutions. What you're asking for - universal software management standardization - can't practically be achieved in more than one use case. This is why we are all constantly stuck in dependency hell, until a bug is filed, and the system is once again massaged into a working state by a human. Frustrating, sure. But it works most of the time.

<comment><USER27> I think it's a stretch to call a tool like npm, which currently offers 90,000+ packages, a "small, bespoke, use-case-specific" solution. I'm also fairly sure most people publishing their code via npm's index aren't spending "thousands of hours" resolving conflicts with other packages by hand; certainly no-one is manually checking over 4 billion pairwise combinations of those packages to make sure they don't conflict.

And yet npm remains a useful tool, and mostly it does what it should do: download a bunch of files and stick them somewhere on my disk. The same could be said for gem, pip, Bower, and no doubt many other similar tools. They just all do it a bit differently, which leads to a huge amount of duplicated effort for both the writers/maintainers and the users of these packages.

I'm not arguing for magic or for orders of magnitude more work to be done. I'm just arguing for the work that is mostly being done already to be co-ordinated and consolidated through standardisation. To some extent I'm also arguing for operating systems that include robust tools to navigate the modern software landscape as standard, mainly because installing things with tools like apt has an unfortunate way of assuming there should be one global copy of everything, which is frequently not the case for either development libraries or end user software on modern systems, and because if the OS doesn't provide good universal package management tools then someone else will immediately invent new tools to fill the gaps and now we are back to having overlapping tools and redundancy again.

<comment><USER9> Again, nothing you use works without it being designed specifically to work that way. You can't use Visual C++ to build software that was designed for Linux without writing portable abstractions and host targets for both platforms, and it _definitely_ won't work on two different architectures without being designed for the endianess and memory width of each. It's bespoke because it's designed for _each use case_. It simply will not work on anything it wasn't designed for.

And no, it isn't code publishers that spend thousands of hours resolving broken and incompatible builds, it's release maintainers. Go look at bug lists for CentOS. Look at the test trees for CPAN. It is literally mind numbing how much shit breaks, but it makes total sense when you realize it's all 3rd party software which largely is not designed with each other in mind. Somebody is cleaning it all up to make it work for you, but it sure as shit ain't the software authors.

Once you develop enough things or maintain enough things you'll see how endlessly complex and difficult it all is. But suffice to say that the system we have now is simpler than the alternative you are proposing.

<comment><USER27> _You can 't use Visual C++ to build software that was designed for Linux..._

Sure you can. Projects of all scales do this all the time. Have you never heard C described as being portable assembly language?

Unless you are writing low-level, performance-sensitive code for something like an operating system or device driver, usually details like endianness matter only to the extent that they specify external protocols and file formats. I would argue that this sort of detail is normally best encoded/decoded explicitly at the outer layers of an application anyway.

Obviously if you rely on primitive types like int or long in C or C++ having a specific size or endianness, or if you assume that they will be equivalent to some specific external format, you're probably going to have problems porting your code (and any package containing it) across some platforms.

However, that issue does not contradict what I proposed. It's perfectly viable — indeed, it's inevitable — to have packages that are only available on some platforms, or packages which depend on different things across platforms. That's fine, as long as your packaging system doesn't assume by default that the same thing works everywhere.

 _And no, it isn 't code publishers that spend thousands of hours resolving broken and incompatible builds, it's release maintainers._

Who is the "release maintainer" who made those jQuery libraries I mentioned in my extended example above play nicely together?

Again, this issue does not contradict what I proposed anyway. In my ideal world, if packages are incompatible or don't have sufficient dependencies available on a certain platform, you just don't list them as available for that platform in whatever package index they belong to. Once again, this is no harder than what a bunch of different package management tools do (or fail to do) right now.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Dependency management (ie class/script/resource loading) is too coupled with the programming language execution environment.

It's not something you can make generic like a file/folder based version control tool. It's like asking for the Git of unit testing/continuous integration or whatever, not going to happen.

<comment><USER29> You can still build your language package manager on top of an existing one. For example, the ebox installer (for the E language) uses 0install to download metadata and package archives, cache things, solve version constraints, etc, but it takes care of actually wiring the language-level modules together:

[http://0install.net/ebox.html](http://0install.net/ebox.html)

It needs to do this because each application is sandboxed. For most uses a generic packager is fine though. After all, most languages _also_ have RPM, Deb, packages etc.</comment></comment>


Ask HN: How to support Tibet as a Software Developer? - <AUTHOR>

How? <comment><USER2> Karma is intention.

You can donate money to monks who are studying, with the intent to benefit all beings. Even just engendering those thoughts has great benefit.</comment>


How did you find your business partners?  - <AUTHOR>

<comment><USER2> We had a major power outage in the Seattle area in December '06 and some areas didn't come back for 12 days (mine was 6). I met my partner at a grocery store while picking up firewood and somehow we talked about how our lives were dependent on computers and the internet :-P. That evening we started poker nights with a few friends where we bounced ideas. Finally, when I was working on my idea and the 2 people working with me QUIT, I was telling him about how hard it was to find a co-founder! And to my surprise, he offered to work on it....now we exhibit great teamwork! Just like the founders of Google, our Bachelors is from Univ. of Maryland and Univ. of Michigan ... LOL

</comment><comment><USER3> When I started a summer project, I used facebook advertising and campus flyers to find potential partners.

I ended getting ~15 hackers interested in working on the project over the summer, interviewed 10, and picked two.

We all worked an lived together in the same apartment. It was probably the best summer of my life, and cost us about $2,000 / person. Most of that was for food & rent.

<comment><USER4> That's a neat approach in that it's something that can be repeated - of course the exact response may vary depending on the nature of your uni.

</comment></comment><comment><USER5> I found mine through past work experience.

I approached two of the smartest hackers I had worked with, and showed them a very brief Keynote presentation followed by a demo of the concept I had been working on part time over the last 6 months.

The Y-combinator application process prompted me to expedite my search for other founders. I was originally planning on launching v.1 of the app before approaching them. Take-aways from this:

 _It is tempting to get a co-founder quickly, if only to validate your idea. That's fine, but don't approach potentials just because you believe there is a high chance of them accepting. Always try to bring in the best people you know.

_ Know that you can work well together. Often said, but it's still worth repeating.

 _Presentations are great, but it's easier to convince someone to spend their time on an idea when you back your presentation up with a demo. Regardless of the outcome, you'll receive valuable feedback, and it's probably good practice for when you meet VCs.

</comment><comment><USER6> My current business partner went to the same highschool as I. He and I became friends because of our love of ideas. We both looked to the future not just as an amusing fiction, but as something we would create. So we were always working on science projects, rail guns, etc.

My initial interest in applying to Ycomb came when a friend of my brother's put an alert out to anyone who wanted to start a business on top of an idea he had around OpenID. I expressed interest and after he discarded his idea, he opted to join my project. However, the connection between he and I was far looser, and eventually he left the group. Interestingly, a day before our third left I told my brother that I had a feeling our third was going to leave. Not particularly useful prescience, but I think it goes to show that if you have a bad feeling about a relationship, you should listen to it.

</comment><comment><USER4> Back in high school I used to get small freelance projects. Every now and then I would subcontract it. And I subcontracted one of the coding projects through a rentacoder.com to what later turned into my partner. We just connected really well and shared a passion to launch new things.

We've done quite a few ventures together in past 4-5 years with MSN chat being our only line of communication:) If we get into YC he'll be flying up to US and hey we might actually finally meet.

</comment><comment><USER7> I met mine through a mutal friend. He had the product idea and could do everything needed except for the technical side of things. My name was eventually brought up and I got a phone call later that night to go over the idea. A week later I had a prototype version ready to demonstrate and we moved on from there. That was 5 years ago and we're still business partners to this day.

<comment><AUTHOR> I'm interested in the relationship between the idea creator and the coder.

I have the idea, but I can't program for the life of me. I've outsourced to people in China but I need to have someone local who can take care of the small stuff.

It just seems that if I find somebody I'll just be telling them what to do while I sit and watch them code...

How do you deal with this?

<comment><USER7> If it was just him giving me an idea then I would have simply done it myself without his involvement. Our product is about teaching guitar. I didn't have any guitar experience while he has nearly two decades worth. He has to produce all the content which is a massive task in itself. The difference is he works on a guitar and I work on a computer. I should make clear the idea is no longer just his. He may have had the initial idea but it's developed a great deal from there to be made up of many ideas from both of us. Ownership of an idea seems to dilute over time. I believe our relationship works because it is equal. Equal decision making power, work load, and business ownership. I think any business relationship where the workload isn't equally shared is doomed to failure. Ideas aren't really worth much. His idea was seemed pretty obvious but we discovered no one was really doing it (due to technical restraints which have only started lifting over the past five years, not through lack of a market ;-).

For a successful business relationship I believe you need to bring an essential skill that helps the project get off the ground, not just an idea. Otherwise, your only alternative is to learn how to code or pay someone to do it.

</comment></comment></comment><comment><USER8> Friends of friends... put it out there to anyone/everyone you know that you're looking for someone with x background or x skills. Let your network do the work. It worked for me!

</comment><comment><USER9> We worked together (directly) in a corporate IT department.</comment>


Windows will delete software that scares users into paying for upgrades - <AUTHOR> https://www.techrepublic.com/article/windows-will-delete-software-that-scares-users-into-paying-for-upgrades/?ftag=COS-05-10aaa0g&utm_campaign=trueAnthem:+New+Content+(Feed)&utm_content=5a71c42f7b44e70007ad2ff6&utm_medium=trueAnthem&utm_source=twitter <comment><USER2> so every antivirus out there?!</comment>