Ask HN: Do you use Vagrant or Docker for active development? - dnt404-1 I think I understand the use case of Docker for deployment, but does Docker hold its sway at the moment for active development. Data persistence support is not out-of-the-box. Vagrant with its own isolated and shared volume support seems like something that would be very good in active development of software artifacts. What is the view of the HN mass, and what would you recommend?<p>Apart from these two, are there any others that looks promising? <comment><AUTHOR> On a Mac or Windows machine you're using Docker with Vagrant via Boot2Docker anyway.

A lot of people us both [http://docs.vagrantup.com/v2/provisioning/docker.html](http://docs.vagrantup.com/v2/provisioning/docker.html)

That's actually the only thing that got me to hold off on Docker the last 2 times I've evaluated it. I was able to get everything running for a 1 monolith + 7 microservice system that I work with but the local developer workflow felt very clunky even with Fig. That was 6 months ago and it's my understanding there have been a lot of improvements.

That project was for a Ruby team and there are so many Ruby based tools that make the local development workflow a smooth operation that shoehorning Docker in locally would have been a step back, so we held off on it.

It's an area that I think will see major improvement though. Heroku's even gotten in on it.

[https://devcenter.heroku.com/articles/introduction-local- dev...](https://devcenter.heroku.com/articles/introduction-local-development- with-docker)

Which is really impressive to me. If anybody in the space can polish out the user experience, it's Heroku.

</comment><comment><USER2> I recently switched to using both, docker running in a Vagrant VM. I've had several frustrating issues with boot2docker on OSX, it's generally just been less stable for me than Vagrant.

In terms of using docker, IMO it's the best development experience I've come across once you get everything set up. It can be confusing to get your workflow set up at first, and it seems like everyone does it a little differently, I'm hoping that best practices will standardize a bit as docker continues to mature.

I love having every part of an app (app code, split into a few microservices if you wish, postgres, redis, rabbitmq, etc.) completely isolated, and docker- compose is a great system for linking things together. I also currently don't have any puppet/chef/etc code and love not having to maintain that, in my mind a large part of the need for configuration management tools is dealing with the complexity of diffing two arbitrary states of infrastructure, and with the immuatable approach of docker containers all that complexity disappears.

<comment><USER3> Did you manage to have automatic code reload set up with Vagrant/Docker? Last time I tried the following config: host folders shared with vagrant VM and vagrant folders mounted inside docker containers. Unfortunately, file change events on host didn't propagate to docker containers. As far as I remember, this was a limitation of Vagrant file system.

<comment><USER4> I'm using the same setup and it works great. Vagrant shares a host folder into the guest VM, and then the docker containers mount subfolders of that shared folder into the container.

So you change a file on the host computer, and it reflects automatically inside the guest VM which is the docker host, and automatically inside the containers since that same location is mounted by the containers.

I just checked the Vagrantfile, and the Ansible playbook we use to launch the docker containers, and I don't see any special magic required to get the syncing working with the Vagrant filesystem, it just works out of the box.

<comment><USER5> Don't you lose inotify this way? Most autoreload solutions trigger on inotify events.

<comment><USER4> No, it works fine for me. The node.js livereload code running inside the container can detect the file changes just fine, and it just alerts the browser running on my host computer via a port that has been forwarded from inside the container to the docker host, and from the docker host to the VM host.

And by the way this setup is bidirectional. If code inside my container, or an SSH session running inside my container makes a disk change, that change is also reflected on the version of the folder that runs on the host.

So if you don't want to go through the effort of doing the port forwarding, you can run live reload on your host machine, and reload the browser automatically in response to changes that were made by the container.

</comment></comment></comment></comment></comment><comment><USER6> > Data persistence support is not out-of-the-box.

This is actually not the case. Although containers do not share any persistent volumes with the host by default, you can use the --volume option[0] to do so.

To answer your question, I've used Docker for local development to run MySQL, Postgres, and Redis inside of containers. Using the aforementioned --volume option, you can share the unix socket opened by either of these services from the container to the host. Otherwise, you can use the --port option[1] to share ports between the container and the host.

I've had a generally pleasant experience using Docker for this use case and would recommend it. It's nice being able to start using a new service by pulling and running an image. Similarly, it's nice to have the ability to clear the state by removing the container, assuming you choose not to mount volumes between the container and the host.

The only frustration I've run into is running out of disk because I have too many images, but it takes a while to get to that point and those can easily be deleted.

[0] [https://docs.docker.com/reference/run/#volume-shared- filesys...](https://docs.docker.com/reference/run/#volume-shared-filesystems) [1] [https://docs.docker.com/reference/run/#expose-incoming- ports](https://docs.docker.com/reference/run/#expose-incoming-ports)

<comment> dnt404-1 Thank you for clearing that up. So, does this work like Vagrant's mount folders? Does the container then find the path to the host's development artifacts?

<comment><USER6> You have to manually specify the folders you want shared in the arguments to the command. For example, running this:

       docker run -v /tmp/:/host-tmp/ ubuntu:14.04 bash -lc "echo 'TEST123' > /host-tmp/test"

Should create a file on your host's filesystem called "/tmp/test" with the text "TEST123".

</comment></comment></comment><comment><USER7> Use Vagrant for everything even tiny projects go in a Vagrant container (isolation is the primary win with the ability to do a git clone, vagrant up and be away).

Don't use any kind of provisioning on vagrant just straight bootstrap.sh as honestly I don't like them.

</comment><comment><USER8> I don't use Docker, although I don't have a need for it.

As a solo coder, I love vagrant - the whole nature that you can use a configuration file with a script or two to build out an entire VM has so many benefits. Less time to build the VM, easily destroy the entire VM, easily rebuild the entire VM, save drive space by destroying the VM when you don't need it, keep the VM configuration in a git repo, distribute the configuration to someone else to use, and the best is having all the steps used to configure the VM are documented in the config file and scripts.

<comment><USER9> Everything you said can be done with Docker, just faster.

<comment><USER10> If he's not on a Linux host that can run Docker to start with, its not going to be faster, _and_ its adding complexity.

<comment><USER11> I was able to get a somewhat serviceable environment up on my Mac. However: after all the effort involved I ended up sticking with vagrant. There is no way I could explain the process to someone I would potentially work with.

I check back in about once every two months to see if there have been any breakthroughs.

<comment><USER12> I have typically created a Vagrantfile to spin up an Ubuntu host with a static IP, configure its' docker to listen on a network port, and 'brew install docker' to get the client on Mac. Set DOCKER_HOST to the vagrant VM IP+docker port, and it's easy to distribute to a team.

I wish the Docker team hadn't more or less given up with boot2docker, since it completely abandons the vagrant advantage of a folder shared with the OS. People do wierd shit like trying to mount their OSX home dir over NFS and, well, Vagrant solved this a long time ago.

</comment></comment></comment></comment></comment><comment><USER13> Vagrant with Docker provisioner:

[https://github.com/czettnersandor/vagrant-docker- lamp](https://github.com/czettnersandor/vagrant-docker-lamp)

Much faster than the Virtualbox provisioner, so it's not an "or" decision, the two thing works well together :)

</comment><comment><USER14> Docker is really great for developing things IMO. I use it in a few ways actually. One thing I've found it really useful for is isolating build slaves in Jenkins (using the docker-cloud plugin in Jenkins).

I also like to use it to create test deployments for debugging or evaluating things, for example it's a lot easier to run Hadoop in pseudo-distributed mode inside a Docker container with host networking, than it is to fiddle with running it in a VM and either getting NAT or DNS working just right, or installing it locally. With the Docker container, if anything goes awry, it's just so easy to get back to initial state by killing the container and starting again.

As for Vagrant, I like it a lot too, but for different reasons. You can define a set of actions that is a lot closer to installing whatever it is you are developing, instead of baking everything together like you do with Docker, which can be desirable. I have used it in the past for creating virtualized cluster environments for integration testing of distributed systems. I think so far I use the VirtualBox provider, but I'm thinking of re-working some of my past uses of it that don't strictly require a VM to use the Docker provider.

</comment><comment><USER15> I use docker for the development of FEniCS, an open source scientific computing package written mixing python and c++. FEniCS requires a lot of dependencies which can be hard to compile (PETSc alike) or need version hold (Boost alike). Docker helps to hold the environment constant. We currently plan to have build bots based on docker as well to streamline build testing.

When I write code inside docker, I always submit to a git repo like Bitbucket. Data persistency is easy. Besides you can always use --volume, which works out of box in Linux.

Vagrant requires some basic shared environment, which is not realistic in my case. For example, I use Archlinux myself and am forced to use old Scientific Linux at work, while many other FEniCS developers use Ubuntu, Fedora, or Mac stuff. It is too painful to write and maintain a Vagrant script for all these (different compiler, boost, blas, lapack and some other 10+ numerical specific stuff). I even tried Vagrant+docker. But in the end, with docker maturing, I switched to docker+bash script instead. It is just more convenient and needs less dependency.

So I'd endorse a docker only approach if you mostly use Linux and your project has a diverse group of people.

</comment><comment><USER16> Working in a consulting capacity, mainly doing LAMP development with a small team. We use a standardized Vagrant image ([https://github.com/readysetrocket/vagrant- lamp](https://github.com/readysetrocket/vagrant-lamp)) which has cut down on a lot of local environment issues for our dev team.

Previously all devs had their own environment (some MAMP/WAMP, some homebrew, some remote, etc) which led to onboarding and support issues. Setting up a standardized recommended dev environment has helped with that a lot - both in terms of reducing project onboarding and getting junior developers up and running.

Would love a day where we can build projects as Docker containers and hand them off to our clients' IT teams, but that seems to be a way off.

SO thread where the authors of Vagrant and Docker weigh in: [http://stackoverflow.com/questions/16647069/should-i-use- vag...](http://stackoverflow.com/questions/16647069/should-i-use-vagrant-or- docker-io-for-creating-an-isolated-environment)

</comment><comment><USER17> I use chef and test-kitchen to bootstrap my dev-VM (vagrant is used by test kitchen). So I have written my cookbooks, and depending on the project, I converge (spinning-up) VMs depending only on cookbooks that I need, eg no java will be installed if the project requires node.js only. In addition the main gain with that, is my dev VMs are totally disposable and they own nothing. Everything is being synced into the VM from my host machine, same with data.

Lately I am trying to "dockerize" my backends, so in the case my workspace project needs a mongoDB or an other backend from my architecture, I should be pulling those containers up on converging. That will make my life easier when writting cookbooks for the backend dependencies.

I believe you can achieve the same using ansible, chef was a personal taste.

</comment><comment><USER18> Vagrant with ansible to set it up. 1 build vm, 6 'deployed' vm's and 1 'deployer'.

Needs a minimum of 42G ram, 150G disk space and fills its logs at 2G/h. Not great when you are running on a 256G SSD.

Building takes 2h+ with ~10% random failure rate due to dependency mirrors and timeouts.

The python code is deployed as gziped virtualenvs to the hosts. This actually works pretty nicely as it means you cant just import stuff and have to build stuff similar to 12 factor style(We dont use ENV_VARS/stdout logging though).

TBH I still dont really see the point of docker, Im sure it will 'just click' at some point but it hasnt happened yet

<comment> dnt404-1 At this point, I too am trying to find "it will 'just click'" moment for docker, though I have only been looking at the two for a few days only.

</comment></comment><comment><USER19> Why not both? We use vagrant to create our docker environment - a 3 machine CoreOS cluster. This is so we accurately represent our production environment.

We then use our production docker image(s) with some more development appropriate configuration options. Vagrant mounts the user's home directory at /Users/<username>/ inside the CoreOS machines. Then we mount the appropriate folder inside the docker container at where the container would normally expect to find the app's code. This way the developers have live updates without having to rebuild the docker image or anything.

<comment> dnt404-1 I have been reading that Vagrant provides a out-of-the-box support for docker after version 1.7. So, it seems this will be easier, and with an obvious case for Windows or Mac.

I am already on Linux, so, my question is why create extra abstraction to it? Is not the function of docker to provide isolation as Vagrant but without the extra overhead of VM. As far as I could gather, one prominent use cases of Docker is the cheapness. Would not doing Docker on top of Vagrant beat that purpose?

</comment></comment><comment><USER20> I would put it the other way around. Docker+Vagrant is best used for deployment and hopefully it will be stable and battle-tested enough so I can use it in production.

I love the fact that once I configured the dev environment on my PC and I hit the road on the next day I can have exactly same environment on my laptop by running single line - "vagrant up". Not to mention that any dev working on the same project saves himself ton of time but not having to configure everything from scratch.

I have not taken the leap of faith yet and I am not using the docker in production but hopefully this will happen soon.

<comment><USER21> I think you wanted to say "Docker+Vagrant is best used for development" ;)

<comment><USER20> Yes! Thanks for a correction!

</comment></comment></comment><comment><USER22> How would you provision the Vagrant box? I would think you'd want to avoid having some Dockerfiles for setting up production servers and some completely different provisioner for setting up development in Vagrant.

<comment><USER12> The idea is that you build a Dockerfile while you are developing, and then you can push an identical environment to production - one of the common causes for production issues being differences from the developers' environments.

<comment><USER22> Yes, sorry, that was my point actually. That once you commit to Docker on production that it probably doesn't make sense to use anything else for development environments.

</comment></comment></comment><comment><USER23> I've used Vagrant for a few projects over the past few years - mostly small things like hackathons and such. Haven't used it much in the past year or so though.

At my last job we used Docker extensively for developing our main software product, based on a Django + PostgreSQL + RabbitMQ + Celery stack. It's definitely a bit tricky to get your head around at first, but after that, it's very nice being able to just type "docker-compose start" and have a working application with consistent configuration ten seconds later.

<comment> dnt404-1 Did you use separate docker container for each of the stacks? From what I can gather, the docker way is to reduce each complexity to a separate container solution.

And, I agree that _docker_ way of doing things is a bit tricky at first, since we are not used to doing things _that way_

</comment></comment><comment><USER24> Vagrant + Ansible for most things. I have used Docker to rebuild some of my environments, and there's a lot of promise, but some hard issues (especially w/r/t more complicated applications with multiple dependencies) that I'm still hoping to make less-hard before switching more to a container-based workflow.

One of my main day-to-day Vagrant configs is encapsulated in Drupal VM ([http://www.drupalvm.com/](http://www.drupalvm.com/)).

</comment><comment><USER25> I've used vagrant for a big rails 3 app with a lot of dependencies and services, i.e., solr, a redis backed delayed_job queue, etc.- stuff that would have difficult or impossible to manage on a mac.

The vm environment was also as close as possible to the production env, with the same os version, etc.

It also greatly streamlined onboarding of new devs. The dev environment setup was a couple of hours instead of a day or two.

</comment><comment><USER26> My team is currently using the gradle cargo plugin ([https://github.com/bmuschko/gradle-cargo- plugin](https://github.com/bmuschko/gradle-cargo-plugin)) to deploy to our remote docker machines for testing. This is my first time hearing about Vagrant. What are it's advantages for our use case for active development?

</comment><comment><USER27> The only use case I had for docker so far was to set up a cross compiler toolchain to produce binaries for an armv7 igep board.

It was significantly easier to tell my co-workers to install docker and type `make local` for local binaries and `make igep` to produce a igep armv7 binary by running a docker container.

</comment><comment><USER28> I use docker extensively for both development and production, using it to mirror the production environment as much as possible. Write code on the host, run on the container. It took me sometime to adjust to the concept but once I did, it was pretty cool.

<comment> dnt404-1 How much time did it take for you to adjust? I still am finding it difficult to wrap the concept of dockerization.

</comment></comment><comment><USER29> I use Ansible and Vagrant for active development of client projects. It's a great combo because it ensures my local environment matches production as close as possible and as well I can go from nothing to running environment with a vagrant up.

</comment><comment><USER30> I use vagrant for all my developments, it was easy for me to setup and play around with some new tools, such as saltstack (configuring master and minions) and reused the same bash scripts to setup the dev env.

</comment><comment><USER31> Not to hijack the thread, just wondering anyone has experience with zero- downtime deployment of multi-container app with cross-container communication?

<comment><USER32> I would definitely check out a number of docker related technologies. To answer your question, we don't have our software out in Docker yet, but it's coming, and it will make a splash when it lands.

Vagrant is a great technology, but I recommend taking a look at Docker compose ([https://docs.docker.com/compose/](https://docs.docker.com/compose/)) previously known as FIG. One of the great advantages of compose is that combine it with Swarm ([https://github.com/docker/swarm](https://github.com/docker/swarm)) and you have a very robust distributed deployment system. Docker-machine is the direct competitor to vagrant, but to be honest, I don't use it. I spin up my docker containers via some build in service API's we already built for proprietary reasons.

If you want to get really robust, you can also look at Kubernetes (and their zero-downtime deployment) and Mesos. These both add a huge amount of complexity t the deployment, but also grant a robust distributed system for managing downtime and deployment. Redhat also has Openshift.

<comment><USER31> Yep, machine/compose/swarm are great tools from Docker and I'm already using it, but compose is more of a "dev" tool so it restarts all containers with every new deploy.

What I'm looking for is a robust and systematic zero-downtime approach to update some of the containers (say in a loadBalancer → web servers → db architecture).

</comment></comment></comment><comment><USER33> Yes, Vagrant only (it is awesome), still not sure what docker does. After setting up a Vagrant VM, I run fabric scripts to build the box for its role

</comment><comment><USER34> Using Vagrant with docker inside for development for some time now and it's been the biggest productivity boost ever, give it a try.

</comment><comment><USER35> Vagrant and puppet. And it's the same puppet we use for production, so we're as close as we can get.

</comment><comment><USER36> I use vagrant to run a multi-vm hadoop cluster for testing.

</comment><comment><USER37> systemd-nspawn and linux-vserver environments with dependencies (library versions, compilers, even python vitualenv) guaranteed by cfengine promises.

</comment><comment><USER38> Isn't it more like Docker with Vagrant?

</comment><comment><USER39> vagrant is okay, but it's kind of a PITA.</comment>


Does Zoom use end-to-end encryption? - <AUTHOR> https://blog.cryptographyengineering.com/2020/04/03/does-zoom-use-end-to-end-encryption/ <comment><USER2> It seems like the root node of this article graph is [https://citizenlab.ca/2020/04/move-fast-roll-your-own- crypto...](https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a- quick-look-at-the-confidentiality-of-zoom-meetings/), which is being discussed here: [https://news.ycombinator.com/item?id=22768494](https://news.ycombinator.com/item?id=22768494)

The Intercept article on it has a discussion here: [https://news.ycombinator.com/item?id=22767807](https://news.ycombinator.com/item?id=22767807)

</comment><comment><USER3> The linked CitizenLab report (titled "Move Fast & Roll Your Own Crypto") is worth reading on its own for more technical details: [https://citizenlab.ca/2020/04/move-fast-roll-your-own- crypto...](https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a- quick-look-at-the-confidentiality-of-zoom-meetings/)

Its key findings:

 _-Zoom documentation claims that the app uses "AES-256" encryption for meetings where possible. However, we find that in each Zoom meeting, a single AES-128 key is used in ECB mode by all participants to encrypt and decrypt audio and video. The use of ECB mode is not recommended because patterns present in the plaintext are preserved during encryption.

-The AES-128 keys, which we verified are sufficient to decrypt Zoom packets intercepted in Internet traffic, appear to be generated by Zoom servers, and in some cases, are delivered to participants in a Zoom meeting through servers in China, even when all meeting participants, and the Zoom subscriber's company, are outside of China.

-Zoom, a Silicon Valley-based company, appears to own three companies in China through which at least 700 employees are paid to develop Zoom's software. This arrangement is ostensibly an effort at labor arbitrage: Zoom can avoid paying US wages while selling to US customers, thus increasing their profit margin. However, this arrangement may make Zoom responsive to pressure from Chinese authorities._

<comment><USER2> That article is being discussed here: [https://news.ycombinator.com/item?id=22768494](https://news.ycombinator.com/item?id=22768494).

It's not clear to me whether the threads should be merged, or—if we're to have only one on the front page—which thread should be the one.

<comment><USER4> I appreciate seeing multiple articles on the front page. It's an important issue right now, and some of the articles can be dense. I like reading multiple presentations of the same information to see what different authors emphasize.

</comment></comment></comment><comment><USER5> Now, I don't think Zoom should have been advertising E2EE when it isn't.

But I think some people are still missing the general point that _E2EE is fundamentally incompatible with general-purpose business /educational videoconferencing_.

It works for Facetime which is designed for small groups exclusively using a Facetime app.

But the second you allow phone dial-in (virtually always a hard requirement), the second you allow cloud recording (which the article acknowledges), E2EE becomes meaningless, because the server itself necessarily becomes another endpoint.

For >99.9% of people this is fine.

For the <0.1% who might be the hand-selected targets of government spying, industrial espionage, or crime enforcement, then no, _you_ shouldn't be using Zoom. But if that's a top priority for you, you weren't already using Zoom anyways -- I assume you'd be using auditable open-source encryption. You wouldn't have trusted Zoom marketing terms in the first place.

<comment><USER6> I don't understand you.

Being from Romania, in all the companies I worked on, we had the need to communicate online by voice and video (mostly with Americans and among ourselves), plus I tended to work in companies with a remote culture. The last time somebody needed to dial into a call I was in was ... 10 years ago. Given we have nearly unlimited 4G data plans for cheap and smartphones, being on the go isn't a problem either.

Since when is this ability to dial-in such a hard requirement?

> " _For >99.9% of people this is fine._"

99.9% of people don't understand what end-to-end encryption is and why it is needed, because they think their calls are secure, when in fact they aren't. It is actually our responsibility to make end-to-end encryption mainstream and to educate people.

<comment><USER7> > 99.9% of people don't understand what end-to-end encryption is and why it is > needed, because they think their calls are secure, when in fact they aren't. > It is actually our responsibility to make end-to-end encryption mainstream > and to educate people.

I'm an academic and a long-time Hacker News reader. It seems that the tech community has collectively decided that _all internet communication -- of whatever sort_ \-- should be secure, all the time.

My first thought, is an outsider, is that this is unnecessarily anal- retentive. But upon reflection, I'm very grateful for this. The more anal- retentive that developers have to be, the less _I_ have to be. If HN is so up in arms about this, it's a very good sign for Internet security overall.

What is it that you'd educate me about? That someone could have snooped in on my departmental meeting? Before Covid-19, these meetings were held in in an open room, in an unlocked building where people walk in and out all day. Anyone with the desire to snoop would have had no difficulty.

From what I understand, enough pressure is being placed on Zoom that they are cleaning up their act. From where I sit as an outsider, the system seems to mostly be working. I'm not angry at Zoom, but I'm very happy that others are.

<comment><USER8> If you have an office where random people can walk in off the street and out again unfettered, that's probably an even greater vulnerability to your company than anything Zoom is doing.

It's like having a car company and saying, "I don't know why anybody would want seatbelts in their car, our cars explode when hit at over 5mph."

<comment><USER7> >If you have an office where random people can walk in off the street and out again unfettered, that's probably an even greater vulnerability to your company than anything Zoom is doing.

This is my point, in reverse.

I work in a university. Thousands of students come each day, to attend class, to show up to professors' office hours, to attend special events. Having physical security in the building would be a huge pain, extremely impractical. I have never heard anyone call for it.

Are there problems? Yes, but they are either minor or very rare. For example, sales reps for publishers will walk in and go to professors' offices door to door. A nuisance to be sure, but not _that_ common.

Occasionally there are more serious problems. For example, in 1978, a Stanford professor was murdered by a disgruntled former grad student [1]. If this sort of thing was even _remotely_ common, I expect you'd see some building security. But it's not.

In the analog world, on average people are just not all that concerned about security. I'm not terribly convinced that they should be.

[1] [https://en.wikipedia.org/wiki/Theodore_Streleski](https://en.wikipedia.org/wiki/Theodore_Streleski)

<comment><USER8> Universities are kind of a special case, I wouldn't generalize on them.

</comment></comment></comment></comment></comment></comment><comment><USER9> Relevant to say Zoom has responded to this.

[https://blog.zoom.us/wordpress/2020/04/01/facts-around- zoom-...](https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom- encryption-for-meetings-webinars/)

"In light of recent interest in our encryption practices, we want to start by apologizing for the confusion we have caused by incorrectly suggesting that Zoom meetings were capable of using end-to-end encryption."

And

"To be clear, in a meeting where all of the participants are using Zoom clients, and the meeting is not being recorded, we encrypt all video, audio, screen sharing, and chat content at the sending client, and do not decrypt it at any point before it reaches the receiving clients."

As others have said, the moment you have to interact with the public phone system, decryption has to happen before the "end".

<comment><USER6> No, that's not a clarification.

What the TFA is saying is that the decryption key is generated by their servers and even passed through China, even if none of the people in the conversation are in China.

That's NOT end-to-end encryption, Zoom never does end-to-end encryption because they have the decryption keys.

And with that clarification they keep deceiving their users.

</comment></comment><comment><USER10> Of all the Zoom articles I've seen over the past few days, I think this is one of the more even-keeled and explanatory (vs the hyperbolic and emotional commentary on HN). I think a level-headed, focused technical discussion (sans incendiary language) does more to advance the conversation than snarky, emotional outbursts. From the article:

"Are we being unfair to Zoom?

I want to close by saying that many people are doing the best they can during a very hard time. This includes Zoom's engineers, who are dealing with an unprecedented surge of users, and somehow managing to keep their service from falling over. They deserve a lot of credit for this. It seems almost unfair to criticize the company over some hypothetical security concerns right now.

But at the end of the day, this stuff is important. The goal here isn't to score points against Zoom, it's to make the service more secure. And in the end, that will benefit Zoom as much as it will benefit all of the rest of us."

<comment><USER11> I read an article on NPR [1] this morning about a guy giving his doctoral dissertation over Zoom. It was broken into by someone putting porn up on the screen and then a few racial epithets as well. I don't think it's unfair to criticize them if this is allowed to happen on their service. Yes we need to keep it civil and yes acknowledge that they are working on fixing it but, given the type of service they offer, I think things like security should have had more focus before they launched rather than dealing with it after the fact.

[1] [https://www.npr.org/2020/04/03/826129520/a-must-for- millions...](https://www.npr.org/2020/04/03/826129520/a-must-for-millions- zoom-has-a-dark-side-and-an-fbi-warning)

<comment><USER12> But isn't that fundamentally s problem with users not setting passwords? A 6 digit meeting key means that if there's 50,000 meetings running at once, each code has a 1/20 chance of hitting an active room.

<comment><USER13> > A 6 digit meeting key

But this is the sort of lack of foresight that bothers me about Zoom. Let's be clear -

\- It isn't that they're being attacked, that happens to any service where there's a payoff.

\- Is is not that they have vulnerabilities, bugs happen.

Is is that they actively tried to deceive about E2E. It is that they never anticipated having 1M simultaneous connections, or the problem that would result before that. It is that they do insecure things to people's machines.

They act like undisciplined malware authors who happen to work on what is supposed to be a business product. What will the next "bug" be?

Actively looking for something that will work for us that isn't so untrustworthy.

<comment><USER14> You nailed it. It is the trust issue. This warning may have absolved them, "your shared encryption keys may be issued from data centers in China". It also would have destroyed their business.

<comment><USER15> It strikes me that if trust was a big an issue to most people as it appears to be to you, the US would have a different president.

I'm not knocking the need for trust, but trusting an closed source code served up by a central server is a bit of stretch for me. The temptation to monetise it is huge, and failing the governments around the world are give themselves permission to order the centralised server to decrypt it and send them a copy, and keep quiet about it. Finally there is absolutely no visibility to keep the vendor honest. They can silently update their code at any point without telling you, include switches that turn any feature off and on without you being aware of it and with little risk of researchers seeing it.

In circumstances like that any "trust" seems to me to be a huge stretch. About the best you can hope for competition is going to keep respecting the customers needs rather than their own need for money. It better to assume it's sent in the clear - which is what I assume with zoom.

</comment></comment></comment></comment></comment></comment><comment><USER6> Zoom is lying in their marketing AND in their recent clarification.

As the article is saying, they always have the decryption key on the server side, so they always have the capability to decrypt the stream.

Given the current state of affairs I wouldn't have minded Zoom not being end- to-end encrypted, but by lying about it, my trust in Zoom plummeted.

</comment><comment><USER16> Article dances around and equivocates. Simple answer is "no".

Whole purpose of E2EE is to assume server is untrusted, but build a secure system anyway.

Zoom can watch & read your content whenever they want to. Full stop.

<comment><USER17> All your cell phone calls can be heard at the providers servers too

</comment></comment><comment><USER18> I wish somebody verified the encryption claims of other companies (like Whereby or GoToMeeting). Zoom is getting scrutiny because it became The Popular Thing, but it's not the only tool.

<comment><USER19> That's part of it, but it's also because E2E is a specific security guarantee which most cloud meeting providers (including in most cases Zoom) don't provide.

Contrast with Gotomeeting's claims[0] that data transmitted between their servers and their users are encrypted using TLS. This is a weaker claim.

[0][https://www.gotomeeting.com/meeting/resources/hipaa- complian...](https://www.gotomeeting.com/meeting/resources/hipaa-compliant- video-conferencing) (third table)

</comment></comment><comment><USER20> > I want to close by saying that many people are doing the best they can > during a very hard time. This includes Zoom's engineers, who are dealing > with an unprecedented surge of users, and somehow managing to keep their > service from falling over. They deserve a lot of credit for this. It seems > almost unfair to criticize the company over some hypothetical security > concerns right now.

I'll have all the sympathy for Zoom's employees who are probably having mandatory overtime in order to keep things running smoothly and to patch things up in response to all the (very legitimate) concerns being brought up, but at the end of the day, Zoom _is_ a for-profit company, not a charity. A for-profit company with links to China [0] that's in a very unusual situation right now and potentially coming in contact with a lot of sensitive information as a great deal of people have come to rely on them. I don't think they deserve to be cut any slack and honestly, the more people find and use other alternatives, preferably open source ones (Jitsi Meet [1], BigBlueButton [2], Jami [3], among others) the better.

[0] [https://citizenlab.ca/2020/04/move-fast-roll-your-own- crypto...](https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a- quick-look-at-the-confidentiality-of-zoom-meetings/)

[1] [https://meet.jit.si/](https://meet.jit.si/)

[2] [https://bigbluebutton.org/](https://bigbluebutton.org/)

[3] [https://jami.net/](https://jami.net/)

</comment><comment><USER21> I feel bad for Zoom right now. They had a great product that people loved, and now all of a sudden they are having an explosion in usage and scrutiny.

And the worst part is that all of this scaling work will be for only a temporary increase. Once everyone gets called back to the office and people can see their friends in person, their traffic will go back down.

Usually if you have an explosion of popularity like this you at least know that your work will be going towards continued growth and revenue.

Having been on the other side of explosive growth, I can empathize with the engineers at Zoom who have to deal with this.

To their credit, they seem to have built a system that can scale pretty well given how well the product has just kept working.

<comment><USER8> People might not get called back to the office for a long time.

</comment></comment><comment><USER22> I think building an iMessage-style PKI might be a wasted effort for them. They would need to immediately and silently inject server "participants" that listen in to every conversation (for dial-in or recording), so the permission model is not much better than a shared ephemeral key. To some extent, the difference depends on logging--if you log the ephemeral key or throw it away (or similarly, if you throw away the made-up participant private key or keep it).

Maybe they should allow small groups to establish on-the-fly OTR-style conversations when they can.

</comment><comment><USER23> > It indicates that the Zoom client — meaning the actual Zoom software running > on a phone or desktop computer — is capable of encrypting audio/video data > to other Zoom clients in the conversation, without exposing your sensitive > data to Zoom servers.

Maybe I'm bad at English, but I had exactly the opposite interpretation. When someone says they "don't" do something, that implies to me that they are able to, but choose not to. Otherwise, they'd just say they "can't".

</comment><comment><USER24> At least we can go self hosted now: [https://jitsi.org/](https://jitsi.org/)

<comment><USER25> Has Jitsi received any serious security scrutiny? Are they also making rookie mistakes?

<comment><USER26> If only people had this type of mindset and attitude _before_ they selected a communications platform.

<comment><USER27> I imagine a lot of these decisions were pretty rushed this year. There are a ton of Universities, businesses, etc, that hadn't previously done any large scale video conferencing. They didn't have much time to do a thoughtful selection.

Zoom is under scrutiny largely because it's a suddenly a highly popular choice. All the hoopla incented skeptics to take a closer look.

<comment><USER26> The fact is that almost none of the communications we use on a daily basis are end-to-end encrypted. What response would you get if you told staff, partners, executives, support personnel, etc that the new standard was based on GPG web- of-trust or hierarchical S/MIME emails and that all plain text emails (or any not digitally signed) were going to be binned at the mail servers?

For that, I don't blame organizations for doing what they had to do - it's perfectly reasonable. But the discussion that results from this is mostly healthy. Zoom will suffer from the PR but I think that will give us better options as a result going forward.

</comment></comment></comment></comment></comment><comment><USER28> Is E2E encryption desirable for video chats with >2 participants?

Let's say I'm talking with two other people: is there a way to do E2E encryption without having to send out the same stream twice?

edit: Just realised a common key would allow this. But I am still interested in schemes for deriving a key amongst multiple parties using a middleman without the middleman knowing the key. It seems like a rather hard problem.

<comment><USER29> > But I am still interested in schemes for deriving a key amongst multiple > parties using a middleman without the middleman knowing the key. It seems > like a rather hard problem.

This is exactly what happens when your browser establishes an HTTPS connection. There are _many_ middlemen between you and the web server, but it still manages to negotiate a shared symmetric key (the session key) that can be used for the bulk of the encryption.

The difference is that there is no certificate authority vouching for each participant in a video call's identity, so you would need to do independent identity verification if you want to ensure that the call is secure, which some people would do by reading the public keys of each participant aloud, and people verifying that everything matches what they see.

<comment><USER28> > The difference is that there is no certificate authority vouching for each > participant in a video call's identity, so you would need to do independent > identity verification if you want to ensure that the call is secure, which > some people would do by reading the public keys of each participant aloud, > and people verifying that everything matches what they see.

This is a good point I hadn't considered. It led to me questioning how signal did it "right," and realising that there is seemingly no way around educating users to check public keys.[0]

So if video chats were meaningfully E2E encrypted, we would need a way to verify the public keys, which afaik Zoom doesn't have.

[0] [https://web.archive.org/web/20160828135326/https://www.inter...](https://web.archive.org/web/20160828135326/https://www.internetsociety.org/sites/default/files/09%20when- signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure- mobile-messaging.pdf)

</comment></comment></comment><comment><USER30> One thing I don't understand is why Zoom is more popular than Jitsi. Zoom charges a subscription fee for meetings longer than 40 minutes, where Jitsi is free for unlimited use. What does Zoom offer that Jitsi doesn't?

</comment><comment><USER31> How the fuck does one even arrive at the possibility of using ECB mode? Even knowing nothing about encryption, I know enough not to do that.

</comment><comment><USER32> what is there to even say at this point. everyones mad at zoom; we hit critical volume for mob mentality and now no amount of discussion or reason matters.

should they have marketed it is e2e when sometimes its not? of course not, theyre wrong.

do you fucking care? do you need more than one hand to count the number of products that are e2e encrypted? if you use the definition of e2e in the article, nothing apple does is e2e either. does anyone else that's not in tech even understand what encryption is at all, much less e2e?

they use a shitty encryption scheme when they do e2e? theyre wrong and should do better.

do you care? your threat model is that someone knows your meeting, is in place beforehand, intercepts the encryption, decodes it, and then spys on your conference?

this couldn't be more of a penny-wise, pound-foolish scenario. why are we still talking about this. please stop

<comment><USER33> Your post seems a little over the top.

Millions are still using Zoom. Its shares are still trading at an enormous premium.

The technical discussion is something altogether different, and people are allowed to have that, regardless of your consternation. And hopefully a better product comes out of it.

"if you use the definition of e2e in the article, nothing apple does is e2e either"

This bit of sad whataboutism is technical nonsense, though. No, Apple, and a number of other vendors, actually do this right.

I honestly think Zoom's engineers, who have made a number of rudimentary serious technical blunders, thought "end-to-end encryption" meant "it's encrypted during every stage of transport". I've seen a number of companies make this mistake.

<comment><USER34> > I honestly think Zoom's engineers, who have made a number of rudimentary > serious technical blunders, thought "end-to-end encryption" meant "it's > encrypted during every stage of transport". I've seen a number of companies > make this mistake.

This means they're incompetent, full stop.

I don't think that at all. I think the marketing team is just full of shit.

<comment><USER35> I think the engineers told the marketing team that they implemented E2E and the marketing ran with it. The same engineers who rolled their own crypto using ECB mode probably thought they were telling the truth. The marketing team probably asked if they had used blockchain too. Until recently they were just another a small company trying to build a customer base in a crowded market.

</comment></comment></comment></comment><comment><USER26> Short answer: No.</comment>


Apple AirPort Firmware Data Deletion Vulnerability - <AUTHOR> https://jcs.org/2019/05/30/airport <comment><USER2> _the previous owner 's Apple ID (usually an e-mail address) and "infinite access token" if "Back to My Mac" had been enabled,_

IMHO this is really the only concerning part because it sounds like something that can be remotely exploited; knowing the wireless network name and key is only worth anything if you know _where_ that network is, and can actually go there and do something.

 _a "factory-default" reset just moves the configuration file to a new location on the device, and the old file and up to two additional previous configurations remain accessible on the device._

 _When doing a factory reset, repeat the process at least three additional times to cycle the data out of ACPData.bin.3._

That sounds like a "last known good configuration(s)" feature to handle the inevitable "I thought I'd reset it because it wasn't working, and now nothing works anymore!" but perhaps the feature was never fully implemented due to other factors.

<comment><USER3> _knowing the wireless network name and key is only worth anything if you know where that network is, and can actually go there and do something_

The AP's MAC address would be the same, which you can just plug into [https://find-wifi.mylnikov.org/](https://find-wifi.mylnikov.org/)

</comment></comment><comment><USER4> How crazy, I quite literally just performed this update. (As in: to test the network post update I went to HN, where I saw this post)

Before updating, I questioned whether I should even bother applying the update, but figured better safe than sorry in case it contained some important security patches. Glad I did!

</comment><comment><USER5> > During our investigation, our team uncovered a workaround that allows users > to fully erase the device by repeating the factory default reset process > four times.

That sounds like an interesting behavior to debug.

<comment><USER6> FTA, it sounds like the firmware's original behavior was to save the three most recent configurations as backups, so it seems straightforward that four resets would have the effect of actually wiping a current config.

</comment></comment><comment><USER7> Why did it take ten months to apply a (what I presume is reasonably simple) change to the firmware reset functionality? All they needed to do was wipe the config backup files when a user factory resets their device and unset a bunch of variables.

A company with as much resources as Apple should not be given this much time before publication. A Project Zero-like 90 days grace period should be fine, especially as you need either physical or SSH access to such a device.

I know Apple tries to make people who report bugs stick to their procedures and agenda but taking over 300 days to roll out a patch for a product that was not seeing any active development regardless? That's quite a lot of patience to keep.

</comment><comment><USER8> Really pretty poor turnaround time sadly

<comment><USER9> I don't disagree, but keep in mind that the entire AirPort product line was publicly discontinued three months before the author reported the problem. I wonder how many other consumer companies would've bothered with a patch at all?

<comment><USER10> Wow, three whole months?

 _I wonder how many other consumer companies would 've bothered with a patch at all?_

Microsoft would have.

For example:

Microsoft is planning to end support for Windows 10 Mobile devices in December. While Microsoft revealed back in 2017 that the company was no longer developing new features or hardware for Windows 10 Mobile, security and software updates have continued. These security updates will now cease on December 10th 2019...

[https://www.theverge.com/2019/1/18/18188054/microsoft- window...](https://www.theverge.com/2019/1/18/18188054/microsoft-windows- phone-windows-10-mobile-end-of-support-updates)

<comment><USER9> Microsoft definitely would have, but they have so many enterprise customers for those products that it's not really a choice; they always plan for LTS.

I was thinking more along the lines of e.g. Sony. There are tons of consumer devices that no longer get updates after they've been withdrawn from the market.

</comment></comment></comment></comment><comment><USER11> Interestingly, it seems like Apple spent the better part of a year delaying the release of the update to fix this issue. I wonder why?

<comment><USER12> The airport team was reassigned to other work in 2016, so presumably it took a few months to allocate time to build a security update for an end-of-life'd product. [https://www.macobserver.com/news/apple-kills-airport- extreme...](https://www.macobserver.com/news/apple-kills-airport-extreme/)

<comment><USER11> The Wireless team has been reorganized, but they have still been pushing out updates for AirPort routers. It seems like they delayed the release of the fix in this case based on the language used in the responses Apple gave.

</comment></comment></comment><comment><USER13> How hard would it be to add Router function to Apple TV box with latest Apple SoC and tvOS?

</comment><comment><USER14> Interesting that it runs NetBSD, I'd imagined it would be a variant of OS/X.</comment>


500 Lines or Less - <AUTHOR> http://aosabook.org/en/index.html <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=11796253](https://news.ycombinator.com/item?id=11796253)

</comment><comment><USER3> I'm liking this trend. Basic ideas of full blown pieces of software often take surprisingly few LOC to implement. Anyone willing to guess how long the first release of git was?. [https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...](https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290)

<comment><USER4> A URL shortener made literate (43 lines) [0]

[0] [http://bitemyapp.com/posts/2014-11-22-literate-url- shortener...](http://bitemyapp.com/posts/2014-11-22-literate-url- shortener.html)

</comment></comment><comment><USER5> Shouldn't it be "500 Lines or Fewer"?

<comment><USER6> I like the Wikipedia article [1] especially the historical use section:

"Less has always been used in English with counting nouns."

Over the years I've changed from prescriptivist to descriptivist. Surprisingly because once I started to teach English my eyes opened to the vast discrepancy between formal grammar and actual use. Eventually I began to realise that language is what people use, not what people tell you to use. I still correct people when they are learning English but I'm only strict where it interferes with meaning. Using less instead of fewer certainly does NOT confuse the meaning.

[1] [https://en.wikipedia.org/wiki/Fewer_vs._less](https://en.wikipedia.org/wiki/Fewer_vs._less)

Edit: jake-low beat me to it - I'll leave the link though

<comment><USER7> I'm generally sympathetic to descriptivism, but I encourage people to stick to prescriptivist rules in situations where departing from them would lead to reputational damage. (Then again, it's probably worse to be branded a pedant...)

Of course this situation is manifestly unfair to ESL speakers, or anyone whose lack of familiarity with formal English leads to misconceptions about their intelligence.

<comment><USER8> It's related to Postel's Law: you can be as prescriptivist as you like for your personal writing, just don't ding other people for being descriptivist, or a second-language speaker.

<comment><USER9> I am very much in favour of common politeness. Also there is the plain fact that there is no rule saying every utterance must have correct grammar and usage.

But style guides that fail to describe the rules that have emerged over the centuries, and which actively avoid giving guidance on edge cases, do not help anyone. Especially not foreigners wishing to learn English.

</comment></comment></comment></comment></comment><comment><USER8> The crawler looked so pretty that I'm hacking away on a real crawler based on coroutines: [https://github.com/cocrawler/cocrawler](https://github.com/cocrawler/cocrawler)

</comment><comment><USER10> Such a short life and so much awesome to learn. Very promising book.

</comment><comment><USER4> The source for the book is available at [https://github.com/aosabook/500lines](https://github.com/aosabook/500lines)

<comment><USER11> Awesome. Can't wait to dig through this.</comment></comment>


Time for Genetic Programming? - <AUTHOR> http://blog.assembla.com/assemblablog/tabid/12618/bid/5680/Time-for-Genetic-Programming.aspx <comment><USER2> Generally, we use GP to make optimizations in exponentially sized search spaces. Lets say you're searching in a 60-dimensional space. If every dimension you add doubles your space, 10 years of Moore's law gets you a ~65-dimensional space.

It's useful to keep in mind that given an entire universe's worth of entropy and a few billion years, the best (apparently) nature could come up with is us.

That said, I do have a few fun ideas:

1\. Evolve a simple natural langague date parsing library (e.g. GNU getdate, but smarter and able to handle noise) over an approximate regex library like agrep. Can you create a regex equivalent to an autoencoder?

2\. Create a database of abstract syntax tree chunks from every OSS project you can find on the web. Try to learn a system that would dump chunks of code into your IDE when you hit a hot key. For example, you could write a method that takes an integer argument, and perhaps it would insert a for loop counting to n. A more intelligent system could take into account instance variables, available methods, etc. Think of it as an extension of statistical natural language methods; like SCIgen (the fake CS paper generator).

</comment><comment><USER3> Biological evolution has thousands of examples of situations where a suboptimal condition exists rather than an optimal one because there aren't mechanisms to remove them. We have bits of code for butterfly wings in us.

How might GP deal with this, if at all?

<comment><USER4> You could make "junk DNA" a fitness criterion, and kill off entities that have lot of it that way. Natural selection doesn't really penalize that, because it has no effect on survivability.

However, it might have a long-term advantage, because of evolution's randomness; if you eliminated the junk DNA you'd also have a much more directed walk through the genome's expression space, which means that you might miss a lot of very good solutions.</comment></comment>


Ask HN: Help I want out I want to leave HN - <AUTHOR> Hi everyone.
I've been a member of this community for a decade plus.
I've used two accounts: TotlolRon and ronilan.
I recently figured this community is not good for me and I want to leave.
I tried to delete all my content (comments and posts) as one can do in other communities (i.e. reddit, Twitter), but I can't. There is no technical way for me to do it and the moderators are refusing to help.
If anyone reading this is willing and or able to help make this happen - I'd be thankful.
Thanks, Ron <comment><USER2> It looks like you haven't comented on your one account since 2010 and the other for 43 days, submissions even longer(besides this one), is it possible what you need is a dns blocker to prevent you from reading the content?

Maybe your router has a white black list that would do this?

</comment><comment><USER2> Heres a comment from a previous thread that covers this topic.

[https://news.ycombinator.com/item?id=19459658](https://news.ycombinator.com/item?id=19459658)

dang:

We delete comments for people nearly every day. It's true that we don't allow wholesale deletion of account histories, because that would gut the threads the account had participated in. But we also don't want anyone to get in trouble from anything they posted to HN.

The idea is to balance the need to preserve history (community interest) and the need to protect users (individual interest). We don't get there perfectly, but I can tell you for sure that the vast majority of people who ask us about this end up happy with how we help them.

<comment><USER3> (I just noticed this thread.)

That's correct. HN generally doesn't remove entire account histories, because that would gut the threads the account had participated in, which is unfair to the commenters who replied. Our goal is to balance community needs with individual needs. pg wrote about this many years ago: [https://news.ycombinator.com/item?id=6813226](https://news.ycombinator.com/item?id=6813226). That doesn't mean we don't care about individual requests. We take care of them every day. For example, we can randomize usernames and disable accounts, and we also frequently delete or redact specific posts that people are worried about.

</comment></comment><comment><USER4> > I recently figured this community is not good for me and I want to leave.

 _Where you think you 're going?_

 _Once you create an account on HN, it is there forever._

All your posts stays right here and there is no way you can delete anything on HN after it is created. It is unfortunate but that's that.

<comment><USER3> We frequently delete or redact posts that users are worried about, and have other tricks to help out as well. The only thing we don't do is delete entire account histories wholesale, because that would not be fair to the other users who participated in the same threads.

</comment></comment><comment><USER5> Generate a random password and change your hn password without saving it anywhere. Remove your email address as well. Now you're locked out.

However, not sure what stops you from simply not using HN. If it is addiction then you'll probably get addicted to something else..

</comment><comment><USER6> What's the problem if you just log out and forget about it? Are you being stalked or fear you might be?

</comment><comment><USER7> Out of curiosity, why do you feel its not good?</comment>


A few speed bumps (Lisp blog series) - <AUTHOR> http://funcall.blogspot.com/2009/03/few-speed-bumps.html

<comment><USER2> Just yesterday I felt the same confusion. I'm working on a JavaScript web application that communicates with a Common Lisp backend using S-expressions one way and JSON the other way (for good enough reasons).

I devised a neat scheme with nested alists and wrote a poorly-specified, bug- ridden implementation of half of Common Lisp in JavaScript to make sense of it all. Then I got really confused for a couple of weeks until I finally figured out why it was so hard to get right.

JavaScript doesn't have a cons or pair type. There's just no way to get cdr and cons to work sanely without being able to juggle Arrays' individual conses. Adding a class for such a fundamental unit and implementing my own linked lists with that would bog everything down just a bit too much. So the house of cards collapsed.

In hindsight it's obvious, but I spent a lot of time wondering why the whole thing was so confusing.

<comment><USER3>
      function cons(x, y) {
          return function(m) {
              return m(x, y);
          }
      }

      function car(x) {
          return x(function(a, d) { return a; });
      }

      function cdr(x) {
          return x(function(a, d) { return d; });
      }

or

      function cons(x, y) {
          return function (m) {
              return m(x, y, function (n) { x = n }, function (n) { y = n });
          }
      }

      function car(x) {
          return x(function (a, d, sa, sd) { return a; });
      }

      function cdr(x) {
          return x(function (a, d, sa, sd) { return d; });
      }

      function setcar(x, y) {
          return x(function (a, d, sa, sd) { sa(y); });
      }

      function setcdr(x, y) {
          return x(function (a, d, sa, sd) { sd(y); });
      }

      function list() {
          arguments.shift = Array.prototype.shift;
          if (arguments.length == 0) {
              return null;
          } else {
              return cons(arguments.shift(), list.apply(this, arguments));
          }
      }

      function mapcar(fun, lst) {
          if (null == lst) {
              return null;
          } else {
              return cons(fun(car(lst)), mapcar(fun, cdr(lst)));
          }
      }

      function reduce(fun, init, lst) {
          if (null == lst) {
              return init;
          } else {
              return fun(car(lst), reduce(fun, init, cdr(lst)));
          }
      }

      function filter(fun, lst) {
          if (null == lst) {
              return null;
          } else {
              if (fun(car(lst))) {
                  return cons(car(lst), filter(fun, cdr(lst)));
              } else {
                  return filter(fun, cdr(lst));
              }
          }
      }

<comment><USER2> That's interesting... I've been thinking about this for a while now and at first I thought it would be incredibly bloated, but now I'm not so sure. Definitely interesting.

<comment><USER3> just for fun:

      function copylist(lst) {
          return mapcar(function (x) { return x; }, lst);
      }

      function last(lst) {
          if (null == lst) {
              return null;
          } else if (null == cdr(lst)) {
              return lst;
          } else {
              return last(cdr(lst));
          }
      }

ugly append:

      function append() {
          var lst = null;
          var i = 0;
          for (; i < arguments.length && null == lst; i++) {
              if (null != arguments[i]) {
                  lst = copylist(arguments[i]);
              }
          }
          for (; i < arguments.length; i++) {
              if (null != arguments[i]) {
                  setcdr(last(lst), copylist(arguments[i]));
              }
          }
          return lst;
      }

the fun:

      function qsort(lst) {
          if (null == lst) {
              return null;
          } else {
              var pivot = car(lst);
              var nlst = cdr(lst);
              return append(qsort(filter(function (x) { return x < pivot; }, nlst)),
                            list(pivot),
                            qsort(filter(function (x) { return x >= pivot; }, nlst)));
          }
      }

      function powerset(lst) {
          if (null == lst) {
              return null;
          } else {
              var first = car(lst);
              var rest  = powerset(cdr(lst));
              return append(list(list(first)),
                            mapcar(function (x) { return append(list(first), x); }, rest),
                            rest);
          }
      }</comment></comment></comment></comment>


Ask PG: x comments display broken ? (or is this a new feature?) - <AUTHOR>

Suddenly the new page no longer reliably lists which discussions have comments and which do not. <comment><USER2> An interesting observation.

 _edit_. It's not just the 'new' page. The new layout appears to be a "discuss" link if there are 0 comments and an "x comments" link when there are comments on any submission.

<comment><AUTHOR> I have one with _two_ comments but a discuss link!

edit: the points display is messed up as well now.

<comment><USER3> Hmmm... so the points display was messed up. I thought the vote discarding system used for comments was being extended to links.</comment></comment></comment>