Ask HN: Why use Docker and what are the business cases for using it? - <AUTHOR> I recently did a very basic tutorial on Docker. Afterward, when talking to the tech lead of the project I am working on, he asked me "What are the business cases for using Docker, how could it save us money, how could it make us more efficient?" I told him I would do some research to find the best answers and figured I would turn to you all here at HackerNews for some advice.
Thanks in advance!
Just so you know, I currently work on a project at my company that uses AWS, Codeship and BitBucket for development and production. AWS and Elasticbeanstalk host our application, Codeship runs tests on changes to branches in BitBucket and then pushes the code that passes on certain branches to different AWS environments for Development or Production. <comment><USER2> Does Docker provide anything useful to someone who develops on OS X and deploys to Linux VMs (Digital Ocean, Linode, AWS)?

Current setup is something like:

\- Develop locally (OS X) \- Test deploy to local Vagrant Linux VM (provisioned by Ansible) \- Deploy to staging/live Linux VM w/ Ansible (or Fabric if I'm being lazy)

I've been following the Docker hype for some time now, but ever time I look into it, I couldn't find any info on how Docker could make my life simpler or easier. If anything, it would just add another complex abstraction layer to have to deal with.

What am I missing?

<comment><USER3> You can build a docker image in a vagrant VM on OSX and deploy that exact docker image to production.

If your vagrant image resembles production, it's probably fine, but there's a level of confidence to be reached from deploying the exact entire self- contained binary, shipping it through QA and staging, and eventually promoting it to production.

<comment><USER4> This is also a use case for not developing on OS X, which doesn't have anything to do with production anyway.

<comment><USER5> Can you clarify? Do you mean that one should only develop upon the platform that will be used in production?

<comment><USER3> Yes, the previous commenter is a purist with no battery life on their laptop.

Further, if you're in the middle of upgrading your production OS, does this mean that you need two developer machines?

C'mon!

</comment></comment></comment></comment></comment><comment><USER6> There are many ways of using Docker and obviously different companies could come up with their own business cases for adopting the technology. So let me focus on one scenario and we can talk about whether it makes sense for your environment.

Software engineering is often difficult because programmers have to deal with inconsistent environments for development and for production execution of their products. Due to mismatches between these environments, developers often found bugs that surface in one environment but not in another.

Hardware based virtualization (VMWare, HyperV, etc) helped with the inconsistency issue because it enabled developers to create dev/test environments that could later be replicated into production. However this category of virtualization requires more computational resources (esp. storage) than operating system virtualization like LXC used by Docker.

In addition to requiring less resources than hardware virtualization, Docker defined a convenient container specification format (Dockerfile) and a way to share these specifications (DockerHub). When used together, these Docker technologies accelerate the process of defining a consistent environment for both development and production in your application. Dockerfiles are easy to maintain and help reduce the need for a dedicated operations team for your application. In buzzword speak, your team can become more "DevOps".

Docker, by the virtue of relying on a thinner virtualization layer than hardware hypervisors like VMWare, also has higher performance for I/O intensive operations. When used on bare metal hardware, you going to be able to get better performance for many databases in Docker containers compared to databases running in a virtual machine guest.

So to recap, Docker can help you

\- maintain consistent dev/test/prod environments

\- use less resources than hardware virtualization

\- free up the time your team spends on dev to ops handoffs

\- improve your app I/O performance compared to running in a hardware virtualization based virtual machine guest

However if you are using AWS, note that Docker Container Service available from Amazon actually doesn't give you Docker on bare metal. That's because Docker Containers run in AWS virtual machine guests virtualized by Xen hypervisor. So with AWS you are paying a penalty in resources and performance when using Docker.

<comment><USER7> Great, but what are the benefits of running Docker in AWS? You are still running VMs and you are being charged for running them. With Docker you are simply putting yet another layer of complexity, because now you have to run more beefier VMs, you now have problem with network communication between containers running on different hosts. So you will most likely need to use overlay network. You also decrease resiliency, because now when AWS terminated a single VM, all apps running on that node suddenly disappear.

I also don't get the argument about running the same container in dev/test/prod. For example my company is working on going Docker and one of the problem with these environments is that app running there has different configuration. So the idea to solve it is to create three different versions of the same container. Genius! But now are you really running the same thing in dev/test/prod? How is it different to what we did in the past? Especially that before Docker through our continuous delivery we actually were using exact same artifact on machines set up with chef that were configured the same way as in prod, while with Docker now we plan to use three different containers.

<comment><USER6> >what are the benefits of running Docker in AWS?

I don't see benefits to running Docker in AWS. In my opinion, AWS implemented its Docker-based Container Service very poorly. I advise my customers against using AWS when want to use Docker. There are many bare metal as a service providers out in the marketplace.

>the argument about running the same container in dev/test/prod

Is this issue really caused by Docker because you said that you had consistent environments when built by chef?

<comment><USER8> Can you name a few bare metal as a service providers?

<comment><USER9> Rackspace, SoftLayer/Bluemix

</comment></comment></comment></comment></comment><comment><USER10> I'd be interested to know if and how people are integrating Docker into their edit-compile-test development cycle?

For me personally, the time it takes from performing an edit to seeing your change "live" on a developer's machine is extremely important. To this end we've spent some effort in making our own services and dependencies run natively on both OS X and Linux to minimize the turnaround time (currently at around 4 seconds).

Docker fixes the "works on my machine" problem, which is worth tackling but not something you run into too often, but (in my admittedly limited experience) introduces pain into the developer's workflow. Right now, I'm leaning towards enforcing identical environments in CI testing and production via Docker images, but not necessarily extending that to the developer's machines. Developers can still download images of dependencies, just not for the thing they're actually developing. I'd love to hear alternative takes.

<comment><USER11> We do a really simple trick. We have one Dockerfile, which we use for dev and for production, every configuration difference is handled through environment variables (which is easy to manage with docker-compose, Ansible, etc.), so you can run the same image everywhere and change the environment configuration to switch between dev/test/prod.

So to solve the live reload problem we do only one thing in development which we don't do anywhere else: the Dockerfile copies all the current source files into the image, but we run the container with a mounted volume of the source code - which in dev mappes exactly the same way the Dockerfile defines the src copy.

This way when you create the image and start the dev container it won't change anything, but as the src is mounted on top of the included src in the image the regular (Rails) auto reload works perfectly.

For test and prod we just simply don't do any volume mounting at all, and use the baked in src directly.

Easy and fast everywhere, all you have to control is how and when the images are created (ex: we do a full clean checkout in a new directory before building a test image, to ensure it only contains committed code. EDIT: by test I mean for local testing, while you're working on revisions, a CI server does the automatic testing).

</comment></comment><comment><USER12> To tell all the cool kids you are using it.

(Ok, I know there are real use cases for Docker, but I see a lot of hype as well. People telling my mathematician friend that she needs to use docker at the start of her project - it is likely to be a one off graph she needs to produce for a research paper).

<comment><USER6> There is a big push for reproducibility in science. If you friend can package the process for building that graph in a Dockerfile, it is more likely that readers of her paper will be able to reproduce her results.

<comment><USER13> or, you know, publish the formula, so readers can reproduce in whatever language / system they want.

Reproducibility is a big push.... but not like you are suggesting. Shipping a dockerfile is the equivalent of saying "This works, _if_ you use this flask, this pipette, this GCMS and this piece of litmus paper"

Docker is not the only solution to problems. It solves some, but you can't tack it on to everything.

<comment><USER14> Why not both? I am not in academia but I was under the impression that some academics might be publishing 'questionable' results that cannot be reproduced at all in order get their paper count up for tenure review. Not to mention puff-pieces from industry that basically serve as PR in peer reviewed journals without furthering their discipline.

So shipping working code (even if it comes with a required pipette) might be a nice requirement for a peer reviewed publication to take on in order to keep their journal relevant. Shipping in Docker or similar guarantees reproducibility.

<comment><USER12> If the code is crap, and only works on one particular data set, then putting it in a docker container ain't going to help.

</comment></comment></comment></comment></comment><comment><USER15> One business use case is to stop threads between the Ops and the Dev team about missing JAR files on a production system.

If Docker was fixing this only, I would still use it. There is nothing better than a single binary deployment that is byte to byte the same as it was running on a dev laptop and a QA env.

<comment><USER16> Do you mean like a war file?

(Yes, I'm being hyperbolic, unless you want to have your entire application running from a servlet container with nothing in front of it. And I agree, a single deployment object is just about the only way to keep your sanity. But still, this isn't the first thing that's proclaimed that advantage.)

<comment><USER15> No, I do not mean like a war file. I am talking about an average Java developer who does not understand how classpath works, how environment works and what are the assumption that is built in to the code and blames everything on other people . For a long time they could get away with this, post-Docker world they cannot.

<comment><USER17> Not sure why you still have this problem. In Java world, Maven build system solved this long, long time ago. There is even a plug-in that builds a uber jar that can be invoked with JVM as the only dependency.

<comment><USER18> Still have problems with Java versions, Java security policies (encryption strength, etc, that you manually have to add files to your JDK/JRE to work), external dependencies, etc.

We use Java, Maven, JBoss + Ear/War deployments. And "Works on my Box" is one of the most frustrating problems we have. This is one of the reasons we're pushing toward Docker.

</comment></comment></comment></comment></comment><comment><USER19> I absolutely love it (Docker + docker-compose) for creating homogenous local development environments. And if your app needs a MongoDB, Elasticsearch or anything else, it's as easy as adding one line to your overall docker-compose config file to link those services to your app. No need to pollute your development machine, you can just have anything running in Docker containers and share them across your team.

I've created several repos on Github for that matter. Here's for example some boilerplate for running Node.js, Express, Nginx, Redis and Grunt/Gulp inside Docker containers:

[https://github.com/b00giZm/docker-compose-nodejs- examples](https://github.com/b00giZm/docker-compose-nodejs-examples)

<comment><USER20> I love docker-compose, it is to services what npm is to packages.

That said, I'm only using it in development. For production there's so many options I don't even know where to begin: [http://stackoverflow.com/a/18287169/3557327](http://stackoverflow.com/a/18287169/3557327)

</comment></comment><comment><USER21> In my experience, if you start hearing: "I don't know what's wrong, it works fine on my localhost!" a lot, then it may be time to think about Docker.

In more general terms: more the complex the environment, the more moving pieces, the more developers on the team, the more servers in production, the more likely there's going be a discrepancy between what Developer-A has running on his machine, and what Developer-B has running on theirs. Docker helps keep everybody on the same page.

For me personally: I'm a dev on a number of projects, and Docker helps me keep my dependencies straight. I no longer have to change things around locally just to work on Project-A, I just get their latest Docker image, and I'm good to go.

<comment><USER22> How is this different from sharing a plain old VM image and doing the same thing? Is there any particular advantage that a Docker image brings?

<comment><USER23> Docker images use the union file system. That means when a new version of that image is available, you often only pull a few megabytes from the hub because it already has the OS.

A docker container is also way more lightweight. Instead of running a full OS, you I only run one process. So your docker image starts within seconds

<comment><USER24> Is this more like a Solaris zone or a Linux chroot-ed env?

<comment><USER9> A lot like Linux chroot, with some additional features, restrictions, and a mechanism to share them easily.

</comment></comment></comment></comment></comment><comment><USER25> Makes system administration somewhat easier since the host OS can stay the same and docker containers change, while giving developers more control. I have total control of which version of packages is installed, which OS I'm using. I don't have to create a ticket, argue over the ask, and get approval just to change an web server timeout. It sort of usurps the sys admin role, though, which might be a negative. I can move my container anywhere that's running Docker and all packages are there inside of the container. If you spend a lot of time setting up new boxes, that's a plus. Before, I had to dump all packages, figure out which ones were missing, then install all of them, and the host OS had to be exactly the same. Now I know it's exactly the same, all the time, anywhere.

My only warning is that using anything but Ubuntu for your build host is going to take way too long and you're going to be waiting hours for it to complete if you don't have any layers cached.

</comment><comment><USER26> It's very useful in situations where you need a reproduceable deployment and also need high performance and direct access to hardware. We run simulations that require a lot of setup, and we tried with VMs at first, but they were too slow and the GL driver inside of the VM didn't implement all the extensions we needed. Docker worked perfectly in this case, though we have to run it in privileged mode.

</comment><comment><USER27> I never figured it out, we could do everything we need in production with LXC, puppet, carton and perlbrew. Combined with a vagrant box for dev, we have no issues.

Although I do use docker to run deluge in a container with openvpn on my home pc, but only because someone else had gone to the trouble of writing the dockerfile and getting it to work.

It seems to break a lot though, when I have time I'm going to get rid of it and replace it with a systemd-nspawn container, because there's less handwaving involved and I can get it to work correctly.

<comment><USER28> Could you post a link to the Dockerfile for the deluge/openvpn container?

I have a VM setup with transmission/openvpn since I was having issues getting the VPN to work with Docker's networking and it was just easier to use a standard VM instead.

<comment><USER27> Sure, this is the one I used, with private internet access.com , [https://github.com/jbogatay/docker- piavpn](https://github.com/jbogatay/docker-piavpn)

I'm sure you could easily change it to work with other VPN providers

</comment></comment></comment><comment><USER29> Something noting is that more and more PaaS (Platform as a service) are using docker.. so sometimes you're not making the decision as a developer to use a docker, you're just forced to use it.

I'm saying this because I know docker solves a lot of pain on the devops side, but on the "software" side it's been painful all the time I've touched it. I.e. practically speaking, it makes releasing much slower, sometimes I'm forced to do a hard reset on the container rather than just reload nginx, etc.

My suggestion is to go with what's simpler for your stack. If you're struggling with having to manage and deploy new configured/secure ec2 instances every day, then it might be worth looking into docker.

<comment><USER30> > _Something noting is that more and more PaaS (Platform as a service) are > using docker_

To expand on this:

* Heroku have introduced Docker-based tools to run their buildpacks outside of their staging servers,

* Cloud Foundry has, in public beta, the Diego scheduler, which can accept and manage Docker images,

* OpenShift 3 uses Docker and Kubernetes as its core components.

Disclaimer: I work for Pivotal, who founded Cloud Foundry.

</comment></comment><comment><USER31> I can give you two first hand examples which also revolve about the apsects osipov mentioned:

#1 is in my dayjob:

We use docker in combination with vagrant for spinning up a test environment consisting of several containers with different components (both ur own products and 3rd party) to run integration tests against them.

The main reasons for this approach are: \- We can supply containers with the installed producs which saves time on automated runs since you don't have to run a setup every time

\- We can provide certain customizations which are only needed for testing and which we don't want to ship to customers without doing all the steps needed for that over and over again

\- We have exact control and version how the environment looks like.

\- Resources are better distributed than in hardware virtualization environments

#2 Is a pet project of mine, a backend for a mobile App. There are still big parts missing, but in the moment it consists of a backend application which exposes a REST API running on equinox plus a database (in an own container).

The reasons I see for using docker here:

\- I have control and versioning of the environment

\- I can test on my laptop in the same components as prod, but scaled down (by just spinning up the database and one backend container)

\- Since more and more cloud providers are supporting Docker (I am currently having an eye on AWS and DigitalOcean, haven't decided yet), switching the provider in the future will be easier compared to having, say a proprietary image or whatever.

\- If I ever scale up the poject and onboard new teammembers, the entry barriers for (at least) helping in Ops will be lower than if they have to learn the single technologies until they get at least basic knowledge of the project.

</comment><comment><USER32> My apologies if I'm hijacking the original poster.

Does Docker handle multi-environment configuration management? For example: qa, stage and live have the same config files, but different values.

Currently we're using Ansible and we set variables for a specific environment, then we feed those variables into config files based on where we're deploying to (config files are not duplicated, only variables that feed into config files.)

All of our configuration is in git and we can quickly see and change it.

How does Docker handle this?

<comment><USER33> One way I've seen many people tackle this problem is to have the Dockerfile/image built in a more generic way, then the end of the Dockerfile kicks off an Ansible playbook (or some other lite CM tool) that will configure everything for the proper environment (e.g. change configuration and kick off a service, something along those lines).

Some will even go as far as using a CM tool to do the entire internal Dockerfile build, and the Dockerfile is just a wrapper around the CM tool. This does require more bloat inside the Docker image, as you need to have your CM tool or whatever other supporting files/scripts installed in the image, but it does make more complex scenarios much simpler.

<comment><USER34> > you need to have your CM tool or whatever other supporting files/scripts > installed in the image

This pattern is maybe even more helpful than harmful, for making your dev environment more closely match production, when your final deploy target is not a docker container.

(You are obviously going to want to see those build scripts running in test, if not earlier; certainly once, before they should kick off in a production environment.) You could do more individual steps in the docker file, just like you could store your token credentials and database handles in the git repository. Neither way is "completely wrong" but there is a trade-off.

</comment></comment></comment><comment><USER35> Side question. I'm well aware of the benefits of docker but, has anybody measured performance degradation due to lack of machine specialization? Back in the web 1.0 days it was common knowledge that you start in 1 server, then you split into 1 app server and 1 database server and you can get 4x the capacity. Did we lose all that with the docker way? Is it not so relevant anymore with modern multicore CPUs?

<comment><USER36> Docker doesn't force you to put your app and your db on the same image. That is up to you. Most have "App" images and "DB" images separate.

If we want to get really specific, Its also common to see the "DB" image split up between the image of the disk where the data is actually persisted, and the image of the actual DB process. This makes it easy to play around with your data under different versions of your DB.

</comment></comment><comment><USER37> If you're familiar with Java, think of a docker container like a WAR or EAR, except it can contain ANY dependency, not just Java code. Database, binaries, cache server, you name it. The implementation is vastly different, but the effect is a deployment artifact that can be configured at build time, and easily deployed to multiple servers.

</comment><comment><USER38> Codeship have a great series on Docker for Continuous delivery on their blog: [http://blog.codeship.com/](http://blog.codeship.com/)

That said I've paged the founders to this thread, they can make the case much more effectively than I can. (disclosure: I don't work for Codeship).

</comment><comment><USER39> Besides just actually running software, I also find it really neat when projects use docker to build their entire application. It provides an effective means of documenting all of your dependencies and making reproducible builds.

Take the docker-compose for example. You can just check the code out, run a single script that builds the project for your environment and everything is pretty much self contained in the dockerfile ([https://github.com/docker/compose/blob/master/Dockerfile](https://github.com/docker/compose/blob/master/Dockerfile)). You don't have to clog up your host computer with deps and you get an executable plopped into an output bin folder.

Additionally, the steps in the dockerfile get cached so subsequent builds are really fast.

<comment><USER40> >making reproducible builds.

Docker builds actually aren't reproducible. There are many sources of non- determinism that Docker cannot address. Do you use the base images from DockerHub as-is or do you run 'apt-get upgrade' or whatever for security patches? If you do, the result you get from building that image (as opposed to using what's in a cache) is different depending on the time it was built. The same goes for any Dockerfiles that compile from source. Hell, just extracting a source tarball results in a different hash of the source tree because of the timestamps on the files. You and I have little hope of building the same image and getting the same exact result.

Build reproducibility is a very interesting topic with some unsolved issues, but Docker isn't helping with it. See [https://reproducible.debian.net](https://reproducible.debian.net) for a good resource about build reproducibility.

<comment> vezzy-fnord Don't know why you were downvoted. Docker doesn't give you reproducible builds because you're still running in a raw host OS environment with all its state, but simply the subsystems partitioned into their own namespaces. Docker is more akin to a snapshot than reproducible.

</comment></comment></comment><comment><USER41> Docker, or containers in general? I'd really like to hear about Docker specifically, but most of the answers so far seem to relate to containers in general, rather than Docker specifically.

What are the business cases for using Docker over some other container-based solution?

</comment><comment><USER42> We have a shitload of servers running CentOS for historical reasons. We can't change the distribution because all the services running on this servers are tight to the quirks and special cases of this distribution. So we need to live with CentOS.

Some of our newer services need a up to date version of glibc and a lot of other dependencies CentOS can't provide. So we use docker to boot up Ubuntu 14.04 containers and run the services with special needs in them.

Another great thing is isolating scripts we don't trust. We allow our customers to run scripts of all kind on our servers --> inside Docker containers. So the customers can't mess with the hostsystem.

<comment> liviu- >running CentOS for historical reasons

Is CentOS not the state-of-the-art Linux distro to run for servers (besides RHEL for support)?

<comment><USER43> Maybe safe-of-the-art. It is stable (and old) which is the way many people like their servers. But, it certainly isn't the latest and greatest.

<comment><USER44> The entire point of RHEL/CentOS is that it isn't bleeding edge; it will certainly be modern though. I think it's rather unfair to call it "old" though; the latest release was in March.

<comment><USER43> Fair enough. But the mentality that picks stable over up-to-date tends to never upgrade. I'm stuck supporting rhel5.5, our "new" systems are 6.5

</comment></comment></comment></comment></comment><comment><USER45> our use case for docker is the following:

we're a webshop, and recently we've standardized our stack on symfony2/nginx/postgresql, so all our websites use that. but beside of that we have some that we maintain that need to run on old version of php/centos.

As we have only 1 server internally for pre-staging environments, docker does help us to save a lot of memory/cpu compare to what we had before (virtualbox, yes...), without needing a lot of machine to setup (like openstack).

Also we don't really have a guy dedicated to sysadmin, so the less time we need to spent on server administration, the better we feel. So we have a set of 3 containers (for symfony+php_fpm / postgresql / nginx ) that already tuned to meet our needs, with a ansible playbook [https://github.com/allan- simon/ansible-docker-symfony2-vagra...](https://github.com/allan- simon/ansible-docker-symfony2-vagrant/) , that we reuse for every new project we have. So that the developers can have a working stack, without needing to reinvent the wheel, they even don't need any knowledge of system adminstration "run this ansible command, done" ! without any risk to break other services.

Also the reproductability and the stateless properties of docker containers has helped to nearly eliminate the class of bugs "the guy that does not work in our company anymore made a tweak one day on the server to solve this business critical bug, but nobody know what it is but we need to redeploy and the bug has reappeared"

</comment><comment><USER46> We have been using docker for about a year at Demandforce, Intuit. We have had a mostly positive experience with it.

Plusses:

\- Dont see any environment related issues because the docker image is the same in every environment

\- Easy onboarding to teams that use docker because you dont need to setup anything new. This is especially useful if your company encourages developers to work across teams

\- Ops can build around infrastructure around this and be sure that every team builds and runs code in the same way

\- If your application is complex, using docker-compose, its extremely simple to setup your dev environment

\- The community is moving towards docker, and it doesnt hurt your resume if you have production docker experience

Minuses:

\- For an extremely simple application (that you think will remain simple over its lifetime), it might be more overhead to use docker than not use it

\- Even though we've been using boot2docker and vagrant to setup docker on MacOSX, it hasnt worked seamlessly. When you get on and off a vpn for example, boot2docker has constantly messed things up. If you can get your dev setup right, docker works well. If not, it can be a pain sometimes on OSX

\- Although its easy to build docker images for most of the open source software out there (if docker images dont already exist), it can be a pain to do that for enterprise software. Try using docker with oracle db. You might get it to work. You wont have fun with it !!

</comment><comment><USER47> I would keep an eye on this project: [http://www.opencontainers.org/](http://www.opencontainers.org/)

<comment><AUTHOR> Heard about this and seems like everyone and their mother are signing on. This is one of the reasons why I asked the main question is because I want to fully understand what the business case is for using Docker.

</comment></comment><comment><USER48> I'm a sysadmin for a private K-8 school. I use docker because of the ease of deploying and upgrading a large number of tools on a limited number of servers.

I've used puppet for several years to manage our infrastructure, and puppet is still managing all our staff and student laptops, but for servers, I've switched everything to CoreOS + Docker.

</comment><comment><USER12> Can people elaborate on when it would be better to use a virtual machine and when it would be beneficial to use a container?

<comment><USER7> If you have own hardware (e.g. Data Center) that is running your own code that you trust. By going with containers you can pack more applications into the same hardware (less overhead), therefore your costs ate lower.

If you running in AWS, you use VMs anyway so the overhead is there no matter what (and also is not your concern, because you pay for the VMs). By adding Docker there you basically adding one extra layer on top of it, so from the infrastructure point of view you making things even more complex.

</comment></comment><comment><USER49> I talk about this a bit here:

[https://www.youtube.com/watch?v=zVUPmmUU3yY](https://www.youtube.com/watch?v=zVUPmmUU3yY)

this was a year ago, so a little out of date. I now work for another company that is into Docker.

I also have various bits on my blog:

[http://zwischenzugs.tk](http://zwischenzugs.tk)

check out the jenkins ones, for example:

[http://zwischenzugs.tk/index.php/2014/11/08/taming-slaves- wi...](http://zwischenzugs.tk/index.php/2014/11/08/taming-slaves-with-docker- and-shutit/)

[http://zwischenzugs.tk/index.php/2015/03/19/scale-your- jenki...](http://zwischenzugs.tk/index.php/2015/03/19/scale-your-jenkins- compute-with-your-dev-team-use-docker-and-jenkins-swarm/)

<comment><USER50> In your Jenkins example, why use docker? Why not ask the devs to directly install Jenkins on their box?

<comment><USER49> Because the builds would not be contained. There were many dependencies that needed to be installed on each box.

Using Docker meant that the slaves could be built from scratch as well.

See here: [http://zwischenzugs.tk/index.php/2014/11/08/taming-slaves- wi...](http://zwischenzugs.tk/index.php/2014/11/08/taming-slaves-with-docker- and-shutit/)

</comment></comment></comment><comment><USER51> We at PeachDish use Docker and Bitbucket to scale our BeanStalk environment. Docker has helped us deploy test site much easier as one can be assured that everything needed to run the app is in the dock. It helps us build consistent environments for testing.

</comment><comment><USER52> simplest case is that it can serve as a multiple staging environment, when you have loads of APP in a single code base (often startups going about prod- market fit). With docker tech shipping speed= production speed. Without docker you are slowed down by 2x or more.Without docker, either you set up a lot of staging environments, which is not great and costly. Or you use one single testing environment and let each of you tech person wait for hours, wasting time, while QA tries to test one branch and you have another idiot deploying another brand on staging. While there are more complex/useful cases, this is one simple biz value i get out of it for my team.

</comment><comment><USER53> Mostly answered already, but another use case is getting engineers up to speed on environments that they're not familiar with. For example, I work a lot with Rails apps, and sometimes we'll need a dev to come in and work some css/html magic or something like that. Well getting them setup with rvm, ruby, rails, bundler, mysql, elasticsearch and working through compilation errors on OSX can be a real nightmare, especially if you set up your env 2 years ago and have just been updating it incrementally since.

When we dockerize the app, they can be setup with the docker image and ready to go in under an hour, without having to screw with their system ... much.

</comment><comment><USER54> Here's a really simple example of a project that I had set up using docker.

For my website I have it set up with continuous integration to run my tests when I merge into master and build a docker image which it then pushes to the docker registry. I then have it ssh into my host server, pull that image, then run the new container and remove the old one.

Boom, i've just deployed my website by simply merging a PR into my master!

This is just a simple use case, and I probably wouldn't suggest deploying a production ready site like this, but it's really cool! It's really simple to just pass around images and have things up and running on local dev's too

<comment><USER27> This is not something that is unique to docker though. I could just as easily set up a hook to deploy our site without docker, but it's not something I need.

I prefer to manually deploy, it's only one command, and I can make sure it's all worked correctly.

That said, I will be moving that command to a chat command, as I like that. But even then, it'll be a manually triggered command.

I have auto deploy setup for CI testing, as in that case I do want to know that those branches are ready for deployment to prod, when I want to.

<comment><USER54> Ahh that's true, I guess what I was getting at was that it makes the deploys much quicker and easier (at least in my experience).

I was also playing around with a chat command to spin up PR's/branches that haven't been merged into master yet, onto a temp container for viewing! Dunno, maybe i'm just not as familiar with other tools that can do similar things as easily

</comment></comment></comment><comment><USER55> In our organization we have seen tremendous value using docker for our CI server (bamboo) and for infrastructure deployment. On the CI server side of things.... Our CI server a.k.a the "host machine" in docker speak has a MySQL database that we did not want used by all of our builds and wanted to isolate the creation of our application from the ground up within using its own MySQL instance. Additionally there is a lot of other peripheral software that we did not want to install on our host machine but it was critical for our unit tests to run. This is where docker is valuable to us from a build perspective. It allows us to isolate the application for unit testing and not get caught up with the possibility of other running software on the same machine affecting the builds, therefore freeing us up from debugging, and therefore saving the company money because developers are not wasting time debugging CI server issues. It's easy to isolate CI server related issues from the docker container running the unit tests because a developer can just run the same tests using the container on their local machine, so it creates a consistent environment.

On the infrastructure deployment side of things.... Previous to our "dockerized" infrastructure we were managing about 7 different AMI's for all our servers and it was becoming a pain in the butt to manage the installation of new software if our application called for it, create a new AMI, then re- deploy said AMI. If you have experience with AWS and you have done this enough times, I'm sure you have faced at one point or another long wait times for your AMI to be created before you can re-deploy with that newly created AMI. This is time wasted on the application deployment side of things, but also on the personnel side of things while you wait for that damn thing to be created so you can re-deploy. Time is money and money waiting for resources to be available or for AMI's to be created is money taken away from the business. Additionally though in its infancy stage, we are using docker-compose ([https://docs.docker.com/compose/](https://docs.docker.com/compose/)) which offers some really nice ways of defining your container infrastructure within a single machine, I highly recommend looking into this for further efficiency.

</comment><comment><USER56> To get some additional viewpoints on containerization, you could also take a look at what has been said about similar, preceeding technologies:

* Solaris Zones, see also SmartOS Zones based on that

* FreeBSD jails

</comment><comment><USER57> I consider it as a replacement for deploying applications as a virtual machine. That is, if I want to host compute and let anyone run any random program in a reproducible manner on my server, I could let them run it in docker and be done with it. So as am IT admin, I find this a useful alternative to letting people run arbitrary programs and add restrictions around it. I think this is more of an IT-OPS tool than something a developer would want to spend time with

</comment><comment><USER58> Say you're running on CentOS 6.6 (or the equivalent RHEL) and you want to run some software that won't work because you need a newer library than is installed (this recently happened to me recently trying to install Transmission).

You have two choices:

1\. Upgrade to CentOS 7.x.

2\. Use Docker and install the software into a container using a newer OS (CentOS 7.x or a newer Debian).

#1 is very expensive and sometimes impossible (if you need to be on CentOS 6.x for compatibility reasons).

#2 is very cheap.

There's one of your business cases right there.

<comment><USER28> This is our current business case. Multiple CentOS/RHEL 6 systems in a global environment and we want to run an application that requires Ubuntu and newer libraries.

Instead of spinning up new VMs in each environment for one new application, we can instead run a Ubuntu container with the application within the existing environment. This brings with it all the other benefits such as continuous delivery and orchestration that we didn't have before.

Once the platform is established there is no limit what we can run within a repeatable and consistent environment.

</comment></comment><comment><USER59> For my project, I wanted to have an automated and easy code to deployment setup, so here's what I have it working Bitbucket -> Private Docker Repository -> Tutum ([https://www.tutum.co/](https://www.tutum.co/)) - Live app

It's working pretty well. Once you check in your code, docker repository hooked to bitbucket will build the docker image and then you can start deployment from Tutum with one click.

</comment><comment><USER44> The only truly compelling case I've seen for Docker is Amazon's ECS, which takes a cluster of EC2 machines and will automatically distribute containers among them where ever there is capacity, according to declared resource needs of a given container. The ability to waste less of your EC2 resources is a very clear business win.

Everything else is still nice, but it's basically "dev environments suck less".

<comment><USER60> FYI this is very similar to Mesos + Marathon. However, both feel way too verbose and painful to use. I'm very interested in seeing how Docker Swarm plays out.

This ecosystem is still so raw.

<comment><USER30> > _However, both feel way too verbose and painful to use_

Try Lattice: [http://lattice.cf/](http://lattice.cf/)

Disclaimer, I work for Pivotal, which developed Lattice based on Cloud Foundry components.

</comment></comment></comment><comment><USER61> I've been using Docker to build a catalogue of similar types of software. Using Docker allows all the software to have the same interface which makes it easier to compare like-for-like. Here's the site - [http://nucleotid.es/](http://nucleotid.es/)

</comment><comment><USER62> Have you ever used provisioning software like Chef to prepare a server to run your software? Have you ever used that in conjunction with Vagrant in order to test out your provisioning and software deployment locally? Docker replaces (or can replace) all of that.

<comment><USER63> Docker does NOT replace configuration management tools like Chef, Puppet and Ansible. Those are still necessary for preparing the host machine which Docker containers will run on. Where Docker does alleviate/reallocate some things is in the configuration of the containers that run on those hosts. Instead of configuring the host for Ruby/Python/etc. you would move that configuration to your Dockerfile. But I think CM tools also have support for generating Dockerfiles, so there's that too.

<comment><USER34> > Chef, Puppet and Ansible. Those are still necessary for preparing the host > machine

In many cases now, they are not. Docker containers can run on CoreOS, which machines are designed to be configured entirely from a cloud-config file, organized in clusters.

With Deis for example, you can build and orchestrate your scalable web service in Docker containers without even writing a Dockerfile, or necessarily knowing anything about how the Docker container is built. The builder creates slugs with the necessary binaries to host your service, and you tell the container how to run itself with a (often one-line) Procfile.

I would still want chef scripts for my database server, but for things that can live in a container on a Fleet cluster, I most certainly do not use Chef, but I absolutely do get reproducible hands-off builds for my runtime environment, and without spending time individually preparing the host machines.

</comment></comment></comment><comment><USER64> Hi, You can have a look at Cloud 66 ([http://www.cloud66.com/how-it- works](http://www.cloud66.com/how-it-works)) a full stack container management as a service in production. Cloud 66 uses Docker technology and integrates 11 open sources tools to cover end to end stack deployment on any cloud provider or on your own server, within one click.

You can compare different Docker solutions ([http://www.cloud66.com/compare](http://www.cloud66.com/compare)) and read how Cloud 66 used Docker.([http://blog.cloud66.com/docker-in-production-from- a-to-z/](http://blog.cloud66.com/docker-in-production-from-a-to-z/)). (disclaimer: I do work at Cloud 66 )

</comment><comment><USER65> This application uses it to spin up replicable instances of genome processing pipelines [https://arvados.org](https://arvados.org)

</comment><comment><USER66> Do people use Docker in conjunction with Vagrant now? Or is Docker used as a replacement for Vagrant for a homogenous development environment?

<comment><USER67> We use vagrant on our dev machines to spin up a CoreOS cluster. Could use something like boot2docker but we prefer the dev environment to mirror production as close as possible.

</comment></comment><comment><USER68> (disclosure: I do work for Codeship :P )

There are a lot of really great reasons to use Docker, or any container technology for CI.

First off containers give you a standard interface to a reproducable build. This means you can run something in a container and expect it to behave the same way as something a co-worker runs on their workstation, or something run in the staging or production environments. For CI this is an absolute necessity. Rather than running tests locally, and expecting a CI server closely tracking the production/staging environments to catch issues with different version of the OS or libraries you can expect any build that passes locally to also pass on CI. This cuts down on a lot of potential back and forth. The only shared dependency between CI/local/prod/staging is docker itself.

Another benefit is (almost) complete isolation. This means rather than having different vm images tracking different projects, you can have a single vm image with docker, and have each container running on the vm for any version of any build across your system. From a CI perspective you can abstract most of the complex configuration for your applications into "docker build -t myapp_test ./Dockerfile.test && docker run myapp_test".

Containers use a differential filesystem, so N running containers for an application will take up 1 X the size of the container image + N x the average space of changes made in the running containers on top of that base image. This makes larger images highly space efficient without having to worry about different instances treading on the same folders.

The line between dev and ops blurs a little (devops), but clear responsibilities. Ops becomes responsible for maintaining the docker infrastructure, and dev is responsible for everything inside the container boundary, the container image, installed packages, code compilation, and how the containers interact. A container mantra is "no more 'well it worked on MY machine'". If it works for the dev, it really will work in prod.

Besides this, there a number of benefits around speed, accessibility, debugging, standardization, the list goes on. There are also a ton of great and varied Docker CI solutions out there, from specific Docker based CI like us (codeship), Shippable, Drone, Circleci, as well as standard solutions like jenkins via plugins. Many hosting solutions are supporting docker redeploy hooks for CI purposes. The standardized nature of containers make it trivial for vendors to provide integrations. Even if you don't use docker yourselves, this is certainly a great space to watch.

Technically you can use docker for CI/CD without using it for deploying your app. When you do this you lose some of the benefits listed, but not all. You lose the cohesion between CI/local and prod, but you still gain a whole lot in terms of speed and complexity within your CI infrastructure.

Thomas Shaw did a great talk at Dockercon on introducing Docker to Demonware for CI across a variety of projects. I don't think the video is up yet, but it's well worth a watch if you're thinking of bringing it into your company. In the meantime we wrote a blog post on his talk: [http://blog.codeship.com/dockercon-2015-using-docker-to- driv...](http://blog.codeship.com/dockercon-2015-using-docker-to-drive- cultural-change-in-gaming/).

<comment><USER68> We are just starting a beta for our new CI flow which follows the container paradigm very closely. It allows you to build docker compose stacks for your various application images, and run your CI/CD pipeline locally, exactly as it would get run on our hosted platform.

If anyone is interested in joining our beta, just drop me an email: brendan at codeship.com.

</comment></comment><comment><USER34> I honestly don't know how much those things cost (I have heard some people say AWS is not cheap, but compared to buying your own hardware maybe all of this stuff is very cheap). The point of asking is, my company has not found a clear place to use Docker directly, but we do use it indirectly through the Deis project, and CoreOS.

My experience with Deis has been wonderful. If you ever looked at Heroku but got to the pricing page and didn't look any further, Deis has the same workflow (and much of the same stack, Cedar) as Heroku. The whole thing is built on docker containers, and designed with failover in mind.

I see that Codeship costs a fair amount of money on the higher end of usage; for the cost of a few months on their enterprise subscription, you could probably build your own CI cluster on Deis. CoreOS also targets AWS, and I don't have any idea what your AWS environment looks like, but you could likely build a Deis cluster on AWS just as easily as you could on your own hardware, if not easier.

I try not to think of Docker as an end so much as a means. For me, it doesn't even matter that it's using Docker under the hood, but if you have containerized your application, Deis can work on already built images just as easily as Heroku works on git repositories.

I can't use Heroku for serious things because it costs too much, and we're small potatoes. But I've got plenty of hardware lying around, and some slightly bigger iron that if I'm being honest is probably underutilized, this is based on knowing that it hosts multiple kernels using virtualization, and the only reason those different tasks run on different machines is to keep them nominally isolated for increased maintainability.

Containerization is "virtualization lite." If I can take those services and jobs that all run on their own virtual machines and make them all run on Deis instead (or even just the ones that don't maintain any internal state of their own), I will gain a resource boost by not having to virtualize all of that separate virtual hardware and individual Linux kernels anymore. The marginal cost of another container is lower than a full virtual machine. If it fits into CI, the maintenance cost is lower too, because that's one less individual system that needs to get apt-get upgrade. If we were better at adopting things like chef, this might not be an argument, but for us it still is.

I inherited a lot of legacy stuff. Your situation might not be anything like mine. If you are already drinking the CI kool-aid, you might not honestly have much to gain from Docker that would compel you to invest time and effort into using it to host your apps.

If Deis looks a little complicated, you might check out dokku. Your laptop probably doesn't have enough power to spin up a whole Deis cluster, but you can still get "almost like the Heroku experience" using Dokku, with Docker under the hood providing support. I'm not going to promise you that it will cut your AWS bills in half, but if you did drink the kool-aid, it might be worth checking out just how much of your currently required development infrastructure and outsourced hosting needs can just go away when you add containerization to your developer toolbelt.

</comment><comment><USER69> well not exactly a business case but it's obviously a win for developers.

I shed a single tear when I realized I could just fire up flask + nginx + uwsgi within seconds after installing docker.

For a business perspective, it's a little tricky. I guess it can help if you need to offer an onsite version of your SaaS app and the enterprise client had strict rules about being on site.

What would really make docker kickass is if they had a way to encrypt all the source code somehow and protect it.

</comment><comment><USER70> Maybe you have looked already and it wasn't useful to you but on the Docker website it has some pretty good marketing to explain its usefulness: [https://www.docker.com/whatisdocker](https://www.docker.com/whatisdocker)

Why Use Docker: "How does this help you build better software? When your app is in Docker containers, you don't have to worry about setting up and maintaining different environments or different tooling for each language. Focus on creating new features, fixing issues and shipping software."

Business Case: "...With Docker, you can easily take copies of your live environment and run on any new endpoint running Docker..."

<comment><AUTHOR> Yeah, I looked at the Docker website. I feel that Docker is super good at marketing and wanted to get some other opinions.

<comment><USER47> Here is CoreOS opinion on docker:

[https://coreos.com/blog/rocket/](https://coreos.com/blog/rocket/)</comment></comment></comment>


Apple gives iPad mini the Retina treatment - <AUTHOR> http://arstechnica.com/apple/2013/10/apple-gives-ipad-mini-the-retina-treatment/ <comment><USER2> How many people who don't skim tech blogs are going to be confused by the difference between "Mini" and "Air"? Both their current iPad lines include a diminutive in their titles.

The smallest MacBook is the Air, but the biggest iPad is the Air? That makes sense. =\

<comment><USER3> Its not about biggest though, its "thinest"

<comment><USER4> The iPad Mini and iPad Air are the same thickness (or thinness if you are in Apple PR). It's a strange naming scheme, especially considering their laptops. The Mini should have been the Air in the first place.

</comment></comment></comment><comment><USER5> Interesting that Touch ID didn't make an appearance on any of the announced devices.

<comment><USER6> Perhaps they wanted to see a period of time with real-world use with the touch sensor on the 5s before going all-in across their entire platform.

<comment><USER4> If that were the case they wouldn't have first used it on their most popular product (and their most profitable). You don't test out crazy ideas on your golden egg.

<comment><USER7> >>You don't test out crazy ideas on your golden egg.

You could consider the idea "crazy" if it was a major change that had the risk of actually hurting your golden egg's success. As things stand though, Touch ID is simply a new feature that has the potential to become more important as time goes on.

From that perspective, testing it out on your golden egg makes perfect sense, since the product's popularity ensures the new feature will get the widest exposure possible. More usage data = more ideas for how to improve the feature.

</comment></comment></comment></comment><comment><USER8> Wait, I thought the whole point of retina was to be a set PPI based on optimum viewing distance. Are we now expected to believe that the new iPad Mini and the iPad Air have different optimum viewing distances that happen to result in the exact same resolution?

<comment><USER9> I think it is a set PPI _or above_ , since 'retina' was marketed as the point at which the eye couldn't detect the pixels. Presumably anything more dense would be considered the same. Since the 10" is a so-called retina display, it stands to reason that a 7" display with the same resolution also is retina.

<comment><USER8> Okay, that makes sense. I take it the screen sizes are also close enough in size that font size difference problems will be minimized? I've been wondering how Apple is going to respond to the need to sell better hardware while keeping their design targets minimal, which IRC is a major developer selling point for them in comparison to Android.

<comment><USER10> Well, in this respect it's the same situation the old iPad mini was in a year ago, and I haven't heard of major problems.

</comment></comment></comment></comment><comment><USER11> When they announced the silly-sounding 'iPad Air' renaming I instantly got excited, hoping for some incredible, maybe 12", iPad Pro. While that left me a bit disappointed, it might be a clue that they're looking into making something bit bigger/more powerful - e.g. remember the iPad in the OR? I imagine there, for instance, a bigger/more powerful iPad could come in handy.

By the way, two (large-ish) hands fit on a 12" display beautifully.

</comment><comment><USER12> I don't really see the point in tablets. At least not if you already have a lightweight laptop and a smartphone. Most people that have tablets seems to just have them lying around. Having a decent touchpad helps too.

</comment><comment><USER13> Having had the 5S for a few weeks now, all I can say is: why did no iPad get the TouchID treatment? I've been enjoying that feature immensely!

<comment><USER14> I wouldn't want to have to use my fingerprint every time I unlock an iPad.

<comment><USER15> Now brace yourself because this might blow your mind. How about switching it off.

</comment></comment></comment><comment><USER16> Does this mean that iPad Air will have 264 ppi screen for a next couple of years? Or the Air is going to get 528 ppi screen?

</comment><comment><USER17> They also gave it the A7/M7.

This makes Apple's product line extremely confusing, and I would predict that the Mini will be the biggest seller by far.

$399 iPad 2 $399 new iPad Mini with A7 & M7 / 2048x1536 display $499 new iPad Air with A7 & M7 / 2048x1536

The Mini seems like the _better_ device of the two, for less! And I don't understand why anyone would consider the iPad 2.

<comment><USER18> The only thing I can think of is it's for corporate or educational buyers who standardized on it for some reason. The 30 pin connector perhaps?

<comment><USER19> Apple has continued sales of old devices to corporate/educational buyers without making them publicly available in the past. The eMac and original iPad were both available to education markets far longer than public markets.

<comment><USER20> The eMac was, but that's because it had it's origins in education. That was also 8 years ago and Apple has changed.

I can't find any corroboration for your assertion about the original iPad. Every source I can find says it was discontinued immediately in favour of the iPad 2. Selling off old stock to the education market isn't the same.

<comment><USER19> My memories of the iPad 1 might be hazy—though I had friends in education that purchased them well after the iPad 2 was available. Perhaps they were getting bulk orders of refurbished (or third party refurbished) units.

The main point is that it's not unreasonable to think Apple would keep products around for enterprise/education markets without selling them publicly, or at the very least without mentioning them during a high profile keynote.</comment></comment></comment></comment></comment>


Ask HN: I forgot my HN password. How could I reset it? - <AUTHOR>

<comment><USER2> If you try logging in with a random password, you should get get a link giving you the option to have a new password emailed to you.

<comment><AUTHOR> Thank you so much, it's so simple! I tried to log in roughly a month ago, but I didn't remember having the password recovery option there. Is this a new feature, or I just missed the obvious?

<comment><USER2> It's one of those undocumented obvious features - been there for a while...:)</comment></comment></comment>


The De Bruijn-Newman constant is non-negative - <AUTHOR> https://terrytao.wordpress.com/2018/01/19/the-de-bruijn-newman-constant-is-non-negativ/ <comment><USER2> A bit rusty on the math, but taking a quick gander at the Wikipedia page ([https://en.wikipedia.org/wiki/De_Bruijn%E2%80%93Newman_const...](https://en.wikipedia.org/wiki/De_Bruijn%E2%80%93Newman_constant)):

"In brief, the Riemann hypothesis is equivalent to the conjecture that Λ ≤ 0."

This result seems to imply that the De Bruijn-Newman constant (Λ) is non- negative, i.e., >=0. Thus, were one able to prove that Λ=0, then one would have also shown the Riemann Conjecture to be true? Similarly, if one were to show Λ to be not equal to 0, then the Riemann Conjecture would be false.

Again, just a quick reading. Sure others who are better/smarter can chime in!

Update: Tao expands on this point in the bottom of his blog post.

<comment><USER3> Yes so if you want to prove the Riemann hypothesis one possibility would be to similarly show some sort of contradiction if Λ > 0\. This is sort of the opposite approach that Rogers and Tao have appeared to use. Of course maybe that side is much much harder (it is equivalent to the Riemann hypothesis after all).

<comment><USER2> I have essentially no real knowledge about this topic, but I suppose some progress has been made by tightening the bounds for this constant?

Can somebody with more info chime in--- is this a huge, groundbreaking amount of progress?

<comment><USER3> I would presume that entirely different methods would be needed to prove that the constant can't be positive. There are many types analytical proofs in math that break down to "negative", "zero" and "positive" cases and often a couple of those are relatively easy whereas others are extremely difficult. The Calabi conjecture is an example.

So really it's hard to say. You might even say this proof made things harder. It guarantees that you have to prove the constant is 0 if you want to prove the conjecture. Before you might have hoped prove negativity.

<comment><USER4> Right, near the bottom of the paper he writes "...this result does not make the Riemann hypothesis any easier to prove, in fact it confirms the delicate nature of that hypothesis"

</comment></comment></comment></comment></comment><comment><USER5> I wonder if it bothers someone like Terry Tao that a question of this requires _so much machinery_ to solve. I'd like to believe him that, say, the work to renormalize the Hamiltonian there is totally correct and rigorous -- he's the best person to believe that it is, anyway. But why is it... necessary?

It seems so completely unlikely that the universe would require going so far afield from the original question in order to prove something that's relatively simple to state about it!

Of course, it's probably because there's some big piece missing -- if you knew how to prove the RH, this would probably be a comparatively trivial corollary. But it _still_ feels kinda weird that all those conclusions couldn't be 'reduced' to something simpler.

<comment><USER6> Undecidability basically guarantees the existence of arbitrarily hard to prove but easy to state theorems.

<comment><USER7> Why is the completeness theorem never mentioned in this context? FOL is decidable! And as far as I can see, RH is in FOL.

</comment></comment></comment><comment><USER8> Scroll to the end of his blog entry. There Terry Tao gives an addendum explaining in layman's terms the meaning of their work:

"ADDED LATER: the following analogy (involving functions with just two zeroes, rather than an infinite number of zeroes) may help clarify the relation between this result and the Riemann hypothesis (and in particular why this result does not make the Riemann hypothesis any easier to prove, in fact it confirms the delicate nature of that hypothesis). ..."

Probably should have been placed at the beginning of the blog for the main content is certainly intimidating.

</comment><comment><USER9> Can someone with more knowledge than me contextualize this result? It appears to be making progress on the Riemann hypothesis, but why is this particular effort getting attention on HN?

<comment><USER10> For context, the author is the notable fields medal winner Terence Tao - [https://en.wikipedia.org/wiki/Terence_Tao](https://en.wikipedia.org/wiki/Terence_Tao) \- and finding the lower bounds for this constant has been a long running endeavor in pure mathematics - [https://en.wikipedia.org/wiki/De_Bruijn%E2%80%93Newman_const...](https://en.wikipedia.org/wiki/De_Bruijn%E2%80%93Newman_constant)

<comment><USER11> Most useful comment here.

</comment></comment></comment><comment><USER12> _If we normalize the Fourier transform {{\mathcal F} f(\xi)} of a (Schwartz) function {f(x)} as {{\mathcal F} f(\xi) := \int_{\bf R} f(x) e^{-2\pi i \xi x}\ dx}, it is well known that the Gaussian {x \mapsto e^{-\pi x^2}} is its own Fourier transform._

Funny that he should mention it: just the other day, my mom and I were having a good laugh because as it turned out mom's neighbor, a Mrs. Cringleton, apparently had no idea that the Gaussian is its own Fourier transform under these circumstances. Apparently it came up over a cup of tea and bicuits they were having, and Mrs. Cringleton felt quite a bit embarrassed when my mom remarked: "But my dear, that is well-known!"

Poor Mrs. Cringleton...

<comment><USER13> Back when I worked at Twitter, celebs used to show up randomly at the HQ at lunchtime. I was just your average Indian immigrant data scientist, not clued into American culture.

The team I was on was trying to hire a lady for a front end eng role. I didn't know what the lady's name was, but I was told she was a very promising candidate, and we were all looking forward to the day when she joined because we had a ton of frontend work.

Ok, so at lunch, my colleague said out aloud - Hey Katy Perry is in the lunchroom! Everyone got excited. So I said, Oh is that the new front end engineer ? The whole room exploded in laughter. I thought I must have made a big social gaffe. My mind quickly raced...,oh maybe she must be a celebrity of some kind. Perry Perry...which Perry do I know...So previous night I was watching some show on TBS and suddenly a Perry name flashed into my brain, so I instantly said - Oh she must be the daughter of Tyler Perry!

The room just doubled up in laughter. Finally I did a wiki lookup and found out who she was. But for days, people would look at me, laugh and say he's the Katy Perry Tyler Perry guy ha ha ha.

Finally I was so embarrassed and pissed off I asked them - Do you know the difference between between Jacobian and a Hessian ? Nobody knew. Well, I said triumphantly, I might not know your katy perry from tyler perry, but atleast I know what I need to know to fo my work.

So yeah, some of us do know that a Gaussian is its own Fourier transform, derivative of an exponential is the exponential itself, etc.

<comment><USER14> So, how does twitter uses Jacobian?

<comment><USER15> A Jacobian is often used in optimisation. In machine learning, optimisation is often relabelled "learning", because they're finding the minimum of a cost function, also sometimes called an error function.

You may have heard of backpropagation. Backprop is merely a convenient way to compute the Jacobian of a feed-forward neural network. The Jacobian computed by backprop is then used to pick a line search direction to minimise the network's error.

Put it another way, a Jacobian is kind of a multidimensional gradient. It tells you in which multidimensions a function is changing the most rapidly.

<comment><USER16> yeah but is most of twitter really using that?

<comment><USER13> no, but most of twitter isn't using knowledge of katy perry's whereabouts either.

Storing garbage info like katy perry kim kardashian etc. in your brain, in my humble opinion, is a tax on your cognition - one pays that tax by being ignorant of elementary methods like fourier transform or multivariable calculus or eigenvalues or trig integrals or T distribution or you get the idea...

<comment><USER16> I'm quite good at math and found your anecdote funny (yes, I know what a jacobian and a hessian are, and give have lectures on using the fourier transform to professional scientists), but honestly most people, including coders, don't need that, and their lives are not bettered by knowing these things. It is a lot bit pretentious, and not humble at all, to judge people for keeping 'garbage' information.

<comment><USER13> I have no opinion on what others should deposit in their brains. Am just saying personally if I start keeping track of garbage info like kate and kim, I tend to forget my trig integrals. I have empirically verified that over time. So given a choice, I choose to be blissfully unaware of these cultural cues, so I can store stuff I deem more useful

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Preprint of paper in arxiv.org: [https://arxiv.org/abs/1801.05914](https://arxiv.org/abs/1801.05914)

</comment><comment><USER18> I'd rather not follow France on a guilt trip.

</comment><comment><USER19> While I thoroughly enjoy Terry Tao's work and am a big admirer of his down-to- earth philosophy, I don't really understand why this particular article is so popular. Indeed, the top comment (which made me LOL, btw) seems to reflect the same attitude.

A much more accesible and enjoyable (though still somewhat technical) article is [this one] [1]

[1] [https://www.google.nl/amp/s/terrytao.wordpress.com/2010/04/1...](https://www.google.nl/amp/s/terrytao.wordpress.com/2010/04/10/the- euler-maclaurin-formula-bernoulli-numbers-the-zeta-function-and-real-variable- analytic-continuation/amp/)</comment>


Rest in Peace, RSS - <AUTHOR> http://www.techcrunchit.com/2009/05/05/rest-in-peace-rss/ <comment><USER2> I found this really ironic because I actually came across this article in my RSS reader. I wouldn't have seen it otherwise.

</comment><comment><USER3> i like how RSS is dead because this one guy doesn't open up google reader anymore.

in other news: i've never visited austrailia, so i posit it no longer exists.

<comment><USER4> When Chairman Rudd implements the great firewall of Australia - then perhaps we shall truly disappear (from online communities at least).

RSS, Email, Phone calls and blogs all aren't going away any time soon. Hopefully in another 5 years or so the stake will be buried completely in the heart of the fax machine - but just because one guys has been distracted by the "oooohh.. shiny" of Twitter - does not the death of RSS make.

</comment></comment><comment><USER5> What's the point of this article? It's as if the author wrote it just because he had to write something, much like how the talkative guy talks about the most useless things just for the sake of talking.

<comment><USER6> Is it just me, or do most TechCrunch (+ family) feel like that lately?

</comment></comment><comment><USER7> You know how fortune cookie fortunes are better if you add "in bed" to the end of them? New rule: add "for me" to every blog post title.

<comment><USER8> If you're feeling snarkier, I'd also suggest "in my useless opinion" for the particularly outrageous claims.

</comment></comment><comment><USER9> Following up on that...

I'd like an intelligent RSS reader that aggregated information from various social sites to tell me which posts are worth reading, preferably normalized based on the number of readers, so I don't get a zillion Engadget posts and zero niche blogs.

The data could come from links from my friends on Twitter, Facebook, FriendFeed, Delicious, etc (after following shortened URL redirects, of course. _sigh_ ), top posts on social news sites I read (namely Hacker News and the various sub-Reddits I'm subscribed to), etc.

It would cross-reference all that data with the RSS feeds I'm actually subscribed to, and present me with ranked list of unread articles, so I can read through the best articles first, and ignore the rest if I don't have time.

Separately it could suggest a few other articles on sites I'm not subscribed to, but might be interested in, also based on all of the above data.

Ideally it would be be "passive", not requiring manual interaction to "train" it, other than looking at my subscribed feeds. If there were some more advanced "learning" aspect to it, it could heavily weight my own actions on social sites, i.e. voting up articles on social news sites, linking to articles, etc.

</comment><comment><USER10> This is what happens when people who used to report on the news, think they are creating the news. Gillmor has an acute version of this disease, as is highly evident from his Gillmor Gang podcast.

</comment><comment><USER11> What we have here is a wonderful example of filter failure.

See this link: <http://web2expo.blip.tv/file/1277460/>

It's a video of Clay Shirky's web2expo keynote titled "It's Not Information Overload. It's Filter Failure."

Here's what's happening: For every wonderful blog post there are several mediocre ones. And when you oversubscribe to RSS feeds, which many of us do, you start drowning in a flood of posts you don't feel like reading.

Links you get on Twitter, on the other hand, are already pre-filtered. Somebody must have already read the article and decided it's worth sharing. You also know from previous experience who is sharing good links and who is sharing crap, so you know whose links are worth clicking.

But this can only work as long as some people keep on reading lots of articles and only share the good ones. You're not gonna get any new links once everyone decides to abandon RSS and only read articles shared by people they follow on Twitter.

</comment><comment><USER9> Some people may like the "firehose" method of getting their news through Twitter, but I still prefer the asynchrony of RSS readers for everything except perhaps breaking news.

</comment><comment><USER12> It seems like the author is being satirical, but there are people that really do think this way.

<comment><USER10> He is 100% in earnest. He's been raving on about this for months on his podcast.

</comment></comment><comment><USER13> Definitely some fluff in the article, but I think his point is simply: "RSS is too slow".

I think this is solvable. One option:

<http://pubsubhubbub.googlecode.com>

</comment><comment><USER14> This stream-of-consciousness style of writing is a sure sign of a fluff piece.

Narrative is not a convincing argument, and two pages filled with "this is so" statements do not interest me.

</comment><comment><USER15> Let's see how twitter manages through the valley of the shadow of spam. Hello, /Dani|Erica|Loni|Heather[A-Z][1-9]{4}/! Thanks for following me. Uh, not.

</comment><comment><USER16> Any blogger who doesn't use RSS isn't worth reading, much less putting at the top of Hacker News.

<comment><USER17> How about the fact that Hacker News doesn't have rss?

<comment><USER14> I have been using this feed for as long as I've known about HN. I can count the number of times I've been to the HN front page on one hand.

<http://news.ycombinator.com/rss>

<comment><USER18> I use this feed: <http://nirmalpatel.com/fcgi/hn_feed.fcgi> which gets me full text of the article with links to the HN comments. Of course, I found it originally in the standard HN RSS feed.

</comment></comment></comment></comment><comment><USER19> This article is annoying, but I agree with the title - RSS never really lived up to its potential. Actually, scratch that - RSS was never the right tool anyway. Neither is twitter, for that matter. And Atom is cool but it's a solution looking for a problem.

What we need is real pub/sub for the internet. XMPP is a kind-of OK first stab but old, ugly and overly complex, AMQP is lovely locally but not really suited for consumers. I get the feeling we haven't cracked this particular nut yet.

And as for Twitter being a replacement for RSS - are you kidding? Is this guy really suggesting that every single RSS source in the world publish their entire feed to Twitter? That would actually be kind of funny, come to think of it. Hardly a solution, though.</comment>


TV Everywhere–A Pivotal Moment in the History of Television - <AUTHOR> http://thefastertimes.com/cyberlaw/2009/12/16/tv-everywhere-a-pivotal-moment-in-the-history-of-television/ <comment><USER2> This is a really important issue from all sides- technological, business, ethical, and more. We think newspapers are dying, but I'd have to say Cable is even worse off. There's something substantial about having printed paper that you can hold at least. It's just making the economics work. With cable, there's absolutely no reason to have it with the internet. It's purely double dipping.

I will tell you this. Comcast and all the others are scared shitless of one thing- hooking your computer up to your tv and canceling your cable subscription. Right now at least they have the value proposition of you being able to easily watch their cable on that new HDTV you bought. Once the 50 inch HDTV screen is as open as the internet/computing itself (im not talking about silly set top boxes btw), they're utterly fucked. Content providers don't need them and their revenue decreases substantially with people just canceling cable.

ps- if this type of vision/stuff interests you on a personal/professional/hobbyist level please please please email me: firstname.lastname@example.com. I'd love to shoot the shit, im very passionate about this topic.</comment>


New EU Privacy Law May Weaken Security - <AUTHOR> https://krebsonsecurity.com/2018/02/new-eu-privacy-law-may-weaken-security/ <comment><USER2> It sounds to me like the WHOIS data is useful to their Internet sleuthing. I have no doubt that it is.

Private investigators in the real world would also have an easier time if we replaced license plates with the owner's full contact information. But we don't. Yes it's a car analogy.

</comment><comment><USER3> > _Moreover, they point out that the overwhelming majority of phishing is > performed with the help of compromised domains, and that the primary method > for cleaning up those compromises is using WHOIS data to contact the victim > and /or their hosting provider._

Then have a way to contact the site owner without publishing information about them, e.g. a registry-operated e-mail forwarder? And for sites operated by commercial entities, requiring some level of contact information should still be legal.</comment>


Ask HN: JQuery vs Google Closure - <AUTHOR>

We are evaluating building a complex javascript / ajax web app.
What is the general opinion on HN on the above libraries? Google Closure hardly gets any mention so want to know if there are any developers out there who use Closure and what has been the experience?
Any other suggestions (backbone?) are also welcome <comment><USER3> They both provide pretty much the same features, but jQuery has had more time and exposure so It is 'probably' a tad more stable.

With regard to backbone and the like it really all depends on your ppl resources. If you want corp support you can forget about it. Sencha's ExtJs might be a better fit.

Also note that backbone and almost all the wonderful modules out there haven't even reached 1.0. It is perhaps this that makes Googles offering compelling as they use this internally and relies on a stable API/codebase.

For the record, I am a big backbone, coffeescript fan.

<comment><USER4> Closure is used in basically every Google product. There's no comparison - <USER2> terms of pageviews, edge cases, and general real-world exposure, Closure is more widely used than probably every other JS library.

I actually think they fill very different niches. JQuery is for sites that are primarily HTML but require some additional interactivity layered on via progressive enhancement. Closure is meant for JavaScript _apps_ , where the whole client is basically written in JavaScript. Closure provides a lot of services that JQuery doesn't - there's a very full-featured widget library, and a JS compiler to minify your code, and a whole module system with on- demand code loading that's critical when your app becomes large.

The flip side is that coding to Closure conventions is very verbose. It feels like Java, a lot of the time. If your app is going to have hundreds of thousands of lines and dozens of developers, this is the right move. If it's just you trying to bang out an interactive website in a couple weeks, JQuery will let you get the basics done in much less code.

<comment><USER5> Does Google considers verbose good?

<comment><USER4> That's not really a meaningful question - Google's a big company with thousands of engineers, and most of them would say there's a time to be verbose and a time to be concise, and knowing the difference is basically experience.

There is a strong belief - at Google and elsewhere - that any engineer should be able to read any other engineer's code. That means getting assumptions down in the code so there's nothing you have to keep in your head.

</comment></comment></comment></comment><comment><AUTHOR> Thanks everyone for the comments. Found a relating discussion on Stack Overflow too: [http://stackoverflow.com/questions/1690197/what-does- google-...](http://stackoverflow.com/questions/1690197/what-does-google- closure-library-offer-over-jquery)</comment>


Mapping time series to Hilbert curve for finding similar time series - <AUTHOR> http://vis.renci.org/jeff/2009/08/24/plotting-timeseries-in-space-filling-curves/ <comment><USER2> I like sticking stuff on Hilbert curves as much as the next person, but I don't see how it makes this particular data easier to understand. It looks like you could do the same thing in as little total space with overlapping line graphs, for example. Am I missing something here because I'm not a quant?

<comment><AUTHOR> I don't think the point is to help 'understand' the data better, so much as to help you find similar series, which is admittedly a pretty narrow goal. That said, I posted it because I hadn't seen this tried, and it was creative, not because I think it's the best way to do this. Honestly, I think the most compact way to really approach this problem would be to make a covariance matrix of all the data and display it as a heatmap, which is probably easier too -- but this is also cool, and a bit surprising.

<comment><USER3> Show me your data please.

<comment><AUTHOR> It's not my data, nor is it my blog.

<comment><USER3> Misunderstanding, sorry.

</comment></comment></comment></comment></comment><comment><USER4> Similar thing, other data sources:

IP address space: <http://corte.si/projects/geohilbert/index.html> and <http://xkcd.com/195/>

Genomic data: <http://www.ebi.ac.uk/huber/docs/btp152v1.pdf>

A portrait of the Hilbert curve as a young fruit salad: <http://corte.si/posts/code/hilbert/portrait/index.html>

and some art.. <http://www.donrelyea.com/hilbert_algorithmic_art_menu.htm>

<comment><USER5> Thanks. I 'blind-spotted' the xkcd URL in your comment, and was going to add it. In the process, I hit the blog post ( <http://blog.xkcd.com/2006/12/11/the-map-of-the-internet/> ) about it - interestingly, it was a rediscovery ...

The 'young fruit salad' tag, for the RGB cube, does take the cake, though ;-)

P.S. If memory serves, there was a neat Python turtle Tk graphics demo which slowly traced a colored Hilbert curve. Perhaps it's the 'fractaldemo' in <http://docs.python.org/library/turtle.html>

</comment></comment><comment><USER6> Followup post: [http://vis.renci.org/jeff/2009/08/24/followup-to-my- earlier-...](http://vis.renci.org/jeff/2009/08/24/followup-to-my-earlier-post- on-hilbert-curve-timeseries-plots/)

<comment><USER5> In the comments, the original author of the Haskell code (Richard Smith) pops up and offers a terrifying 'golfed' one-liner version ...</comment></comment>


Mathematical Foundations of Quantum Mechanics: An Advanced Short Course (2016) - <AUTHOR> https://arxiv.org/abs/1508.06951 <comment><USER2> lol checkout exercise 33 solution on page 23</comment>


Andreessen and Horowitz Complete Raising $300 Million Venture Fund - <AUTHOR> http://kara.allthingsd.com/20090612/andreessen-completes-raising-dough-for-his-300-million-venture-fund-let-the-investing-begin/?mod=ATD_rss

<comment><USER2> It's amazing what credibility/track record can do. Even in the recession time they still can raise $50 million more than planned. I think, this is a great proof of "investors invest in people"

</comment><comment><USER3> A venture capital fund claiming a 7-10 year time horizon on investments? I'm torn between "About time" and "Yeah right".

<comment><USER4> In Scandinavia, the typical length of a VC fund is actually 10 years with a standard option to extend for 2 years. First half (5 years) for new investments, second half for followups and then 2 years for padding (option to be exercised at the management company's discretion, not the LPs). I would assume a similar setup is common overseas.

So if you're part of an investment out of a young fund then you typically have at least a 7 years time horizon. Obviously things have to go well in the meantime or they won't sustain you for that long. But the difference between a Marc Andreesen VC and any other VC is def not the length of the fund.</comment></comment>


Ethics: a company goes back on its promise to pay interview travel expenses? - <AUTHOR>

This is just an honest question. Please advice.
I had an interview with a company in Herndon VA. Its a software company and I was being interviewed for an open position there. I live in Manchester, NH. I was told that they will reimburse up to $750 of the travel expenses. I was given only 1 day notice to be at the interview. I understand that I could have negotiated the interview date, but thinking that:
1. They are paying up to $750, I might be able to make it. 2. The program manager apparently had only that time slot available in the entire week (who apparently did not show up).
So, I said I will be there. I had cleared three phone interviews so far. This was supposed to be the final in-person interview. Unfortunately, I was not selected even though I do feel my interview had gone well.
So, in such a short notice, I booked a flight and a car and the cost came out to be around $700. I submitted my expense report and receipts later and was told to wait till the payroll runs. I followed up after a month and they said they cannot process it because it is too much of an amount. I sent the finance personnel the email sent by HR that they have up to $750 for me.
Then he called me and started to haggle/bargain this price with me. I do not have a job at present and I hope people here at HN know what is it to be jobless and still take out close to 1000 bucks.<p>It has been 2 months now and despite my several emails, they do not even reply.
What are the ethics here? I have original receipts and I have their emails.
What should I do?
Am I right in asking them that reimbursement as they had promised? <comment><USER3> The ethics are clearly in your favor, but it's highly unlikely that formal legal actions will result in any net dollar gains on your part. I'll explain.

Assuming you've completely exhausted casual diplomatic channels, I would firstly send out a formal "letter of demand" (registered return receipt) which includes an itemized list of your expenses, copies of your receipts, the relevant correspondence, and "pay-by" date (usually 30 calendar days from post-mark). Think of it as if you're formally presenting your case to a judge, but that judge is pre-disposed to rule against you. Be thorough.

Legally, assuming you have documentation to back-up their $750 budget, their request for your physical presence, and your $700 of expenses, it looks like a clear case of "breach of contract".

The only flimsy legal leg the company might have to stand on is if the particular HR representative didn't have "agency" to represent the company in your travel reimbursement negotiations (highly unlikely since it seems as if you've already spoken directly with someone who's post-facto implied such an agency by haggling).

I live in Northern Virginia just south of Herndon. FWIW, IANAL, but as a business owner, home owner, and investor, I have more than a passing personal expertise in VA commercial contract law at both the small-claims and general district court level.

If, after the formal demand letter, they don't pay-up and you still wish to pursue formal channels, the amount falls under small-claims statutes. Technically, you'll be filing for a "warrant in debt" [PDF] <http://tinyurl.com/2fk54ce> rather than "breach of contract". This is both good and bad. It's good since the current general case docket in VA right now is about 10 months.

It's bad in that, as a person, you MUST represent yourself in small claims court in VA. Only a company has the "luxury" of formal in-court legal counsel under small claims in VA. At the minimum, you're going to incur a risk that your additional filing and travel expenses to/from the hearing itself may not be included in the final judgment (most of the time they aren't). Nevertheless, you'll want to include them for possible liens, etc. Much like taxes, don't be afraid to itemize. Since it seems that some time has past already, don't forget to include interest.

If the company is not properly registered in VA (check here <https://sccefile.scc.virginia.gov/> ) you'll have to file suits against its owners. One other "gotcha" that particularly litigious companies will often try to do is opt for a formal transfer of your case to the normal civil docket. If they're already paying retainers for legal representation, it costs them essentially nothing to try.

Amortize these formal efforts over time. I suspect that your individual attention is worth far more than the resulting hourly rate.

<comment><USER4> Note also that there's a small cost to filing a small-claims case in VA - <USER2> believe it's the cost of getting the warrant served. Last I checked, it was in the neighborhood of $80. Sadly, @bonsaitree is probably right: even if you win, this probably isn't worth your time. One thing you might try, which worked for me once, is to type something up that resembles a lawsuit and mail it to them with a note that you're about to file this, so this is their last chance to settle first.

<comment><USER3> Um, I _HIGHLY_ recommend that you _DO NOT_ do this.

Technically, you are mis-representing yourself as an "officer of the court" (e.g. a firm which employs people who have passed the Virginia bar). It's a crime similar to impersonating a law enforcement officer.

However, along these lines, it's perfectly reasonable to hire an attorney (some will do it gratis or for an extremely small fee) to draft a follow-up "letter of demand threatening suit" in their office's letterhead.

In practice, all this does is intimidate the legally ignorant (e.g. not normally any kind of corporation) since the attorney must go through the exact same legal hurdles as the debtor and the amounts involved in this case would never be worth engaging the firm's personnel.

Essentially, these levels of disputes are "write-offs" and "costs of doing business" to those who can afford to hire an attorney in the first place.

The _only_ reason to engage an attorney here is if you wished to wage a profitless, but potentially damaging, negative PR campaign (think Gloria Allred) against this firm.

</comment></comment></comment><comment><USER5> Perhaps they didn't hire you because they are having money troubles? It sounds like that could be a problem with them.

People will generally do something if it becomes more of a problem for them NOT to do it. You said it's been 2 months and you've ONLY sent "several emails."

You need to set aside 15 minutes per day and call them every single day until you have your money. You need to become a big pain in their ass so much that they know that at 11am they are going to receive a call from you asking where your re-imbursement is. Don't email because they can easily be deleted. You need to phone and be polite but firm.

You are definitely right here to get this money.

<comment><USER3> FWIW, that sort of phone behavior can be construed as "harassment". Additionally, VA is a "one-party" wiretap state so the company could very easily record the content and frequency of these phone calls and have your number blocked, and/or file a criminal complaint against you.

You are correct in that emails can be deleted, logs altered, and records "misplaced".

A single written demand letter (sent registered return receipt) by USPS is all the "notification" necessary.

<comment><AUTHOR> I see. Thanks.

</comment></comment></comment><comment><USER6> Mail them that if they don't re-imburse you promptly that you will name them publicly ?

They can't really fire you and they won't be hiring you. I don't expect they'll be suing you (but that's always a chance).

If I were them I'd pony up.

If you have it in writing get a (friendly, so it won't cost you more $) lawyer to write them a nastygram first ?

<comment><AUTHOR> I have their HR's email stating that they have reserved $750 for me from corporate so that I can be reimbursed. I just am not sure if this is my right. I mean, they did promise me and I have their email stating that but isn't it their discretion?

<comment><USER6> As far as I can see it is a 'contract', they said if you do 'x' they'll re- imburse you, you did 'x', they should pay up.

It's definitely not at their discretion to haggle or refuse after the fact.

Until you ordered that ticket they could have backed out.

I'm really surprised they would do this, no reputable firm would mess up like this.

Also makes me wonder if you're the first.

<comment><USER7> > As far as I can see it is a 'contract', they said if you do 'x' they'll re- > imburse you, you did 'x', they should pay up.

I'm not a lawyer, though I do think you are right in this instance.

One thing to keep in mind though is that if an employee does not have the authorization to make such an agreement then the company isn't liable.

I forget the legal term for this type of person, agent comes to mind.

<comment><USER6> > One thing to keep in mind though is that if an employee does not have the > authorization to make such an agreement then the company isn't liable.

I don't think that it is that simple. If a worker for the city cleaning department comes up to you and offers to sell you a small building the city owns then yes, the city is not bound because you can assume that he has no such authorization.

But if the mayor of the town would make you an offer to buy a small building the city owns (in writing) then you'd definitely have a case of sorts, even if it turned out afterwards that he did not have the authority.

It's all about the expectations of authority on the part of the recipient, if those expectations are in line with the function of the other party. And in this case it is perfectly ok to assume that if an HR person from a company offers to re-imburse you for your costs if you make the trip that they will actually do so.

<comment><USER8> as always, Im not a lawyer.

It may vary where you are but in Australia if its reasonable for you to believe the employee has the authority to make such an agreement then its binding (everything else being equal). The employee's actual authority isn't relevant.

Otherwise people saying "oh, they didn't have the authority" becomes an instant way to wriggle out of any deal after the fact and contracts everywhere become worthless.

Side note: this is one of the big reasons why big companies are so strict in their rules about low ranking employees speaking to anyone within their premises or while wearing anything identifying you as employee. It suggests you are an agent of the company and thus speak for the company.

When I worked in a large supermarket chain many years ago all staff but store management were absolutely forbidden from speaking to anyone about pretty much anything because we were agents of the company and thus could be presumed to be speaking for the company.

</comment></comment></comment></comment></comment></comment><comment><USER9> Be very pleased that you _didn't_ get a job there - if they treat job applicants like this they will probably treat their employees just as badly.

<comment><AUTHOR> I totally agree. Perhaps, it is a boon in disguise.

<comment><USER8> -Well, that represents quite a boon.

-Oh, an enormous boon.

-Well, we're always on the lookout for enormous boons.

<http://www.youtube.com/watch?v=0nTmSu6v0LA>

</comment></comment></comment><comment><USER10> Wow, ask them to pay you what you're owed and what they promised, absolutely and finally. If they still beat around the bush, remind them about the reputation of their company and how you feel that the public disclosure of the way they treated you would not benefit their recruitment.

</comment><comment><USER11> You are absolutely right in forcefully requesting the refund. They're jerks for making you ask twice.

Absolutely do not threaten them in anyway. Do out them in public if they don't make it right.

</comment><comment><USER12> Isn't this a good case for small claims court?</comment>