kroo's comments

A quick google turns up lots of people agreeing with you, suggesting the intel wireless driver seems to have trouble on 802.11n. Fine. But 8?

    modinfo iwlwifi

    parm: 11n_disable:disable 11n functionality, bitmap: 1: full, 2: disable agg TX, 4: disable agg RX, 8 enable agg TX (uint)

Side note: 11n_disable=8 as a way to enable an advanced wifi settings is not the most user-friendly option in the world. It looks like this was added as a patch to fix a compatibility issue with certain NICs[1]. Be careful setting it higher than 8 -- as that would set other flags in the bitmask, potentially turning off 802.11n entirely!

I've not heard of AMPDU before -- but it seems to be an 802.11n-specific protocol extension that allows you to send multiple MPDU blocks (i.e. frames) to the router at a time, rather than one at a time. This seems to trade off latency for error correction between a client and the router [2][3]. So by setting this flag, you're able to transmit multiple frames at a time, rather than retrying each frame individually until it goes through on a busy channel. This really does seem to make a difference, one report online suggests tx throughput goes from 20Mbit/s to 80Mbit/s when agg TX is enabled[4].

Apparently this was introduced in 2014 in order to patch a firmware issue on certain intel NICs. There's a whole conversation on the linux-wireless list about it[5], which seems to conclude that they couldn't reproduce the issue[6]:

> I have seen reports from many users and many devices - and unfortunately I have never been able to reproduce - so I can't know if it affects all the devices. All I can see is that I saw reports on very old devices (5150) and with more recent devices (2230).

[1]: https://github.com/torvalds/linux/commit/205e2210daa975d92ac... [2]: https://routerguide.net/optimize-ampdu-aggregation-on-or-off... [3]: http://eprints.eemcs.utwente.nl/21008/01/eunice.pdf [4]: https://ubuntuforums.org/printthread.php?t=2205924&pp=75 [5]: https://www.spinics.net/lists/linux-wireless/msg118549.html [6]: https://www.spinics.net/lists/linux-wireless/msg118554.html

Midnight commander (and more generally an orthodox file manager) is especially useful for moving files from one system to another, as it usually supports browsing to remote file systems over ssh or ftp, and gives you a simultaneous view of where you're moving files from and to on the same screen.

The Wikipedia page is a pretty interesting read, actually: https://en.m.wikipedia.org/wiki/Midnight_Commander

> One of the unique design features of the microscope is the use of inexpensive spherical lenses rather than the precision-ground curved glass lenses used in traditional microscopes. These poppy-seed-sized lenses where originally mass produced in various sizes as an abrasive grit that was thrown into industrial tumblers to knock the rough edges off metal parts. In the simplest configuration of the Foldscope, one 17-cent lens is press-fit into a small hole in the center of the slide-mounting platform. Some of his more sophisticated versions use multiple lenses and filters.

http://imgur.com/a/WkWtP

And PDF:

http://cl.ly/3Y423m390Y1Z

Edit: added imgur album.

If you run things on App Engine, I highly recommend subscribing to the downtime notify list -- it's much more responsive and accurate than the App Engine status page in my experience.

https://groups.google.com/forum/?fromgroups=#!forum/google-a...

This thrill of creation, when you've got the design (momentarily?) cracked and all that's left is the small matter of putting to disk what's there in your mind already, describes some of the most exciting experiences I've had writing code.

Edit: As I read it, this is pretty straight forward, doing the following things:

- Makes it explicitly legal to operate an autonomous car on public roads, if your car has met a safety standard yet to be devised.

- Authorizes the establishment of safety standards for autonomous vehicles by the California Highway Patrol.

- Until these standards are devised, it does not prohibit autonomous cars from operating on CA public roads.

"Autonomous Cars" in this case are defined fairly narrowly: a car capable of driving "without active control and continuous monitoring of a human operator".

    print "\n".join(map(str, range(1,1001)))

    print "\n".join(str(i) for i in range(1,1001))

Another former etherpad employee here. I just wanted to point out that contrary to the comment above, there's a fair bit of active open-source development on etherpad these days, though the folks there could always use more help. Head over to https://github.com/ether/pad and pitch in!

This is absolutely true, which is one thing that makes (working at) this company so interesting/challenging.

On one front, without technology development, you can't scale without a lot of capital investment -- even the custom technology used by zipcar is cost prohibitive (around the $1000 price-point, and requires several hours of professional installation). While we support swapping keys with the renter, we don't want to open both parties up to the inconvenience and liability of handing your keys over to a total stranger. The carkit provides greater choice to the owner as to how they want to rent out their car (allowing them use a smartphone instead of the physical key), and empowers them to keep better track of how it is used when rented out.

On the other, as you put it, technology doesn't solve all these prickly complications -- there are serious operations, customer support and business development problems that must be met in order to make this work. Insurance is a critical piece in the puzzle, and one that our team has been working on for a year and a half now. We are confident in our insurance partner and the custom policy we have worked together to create at this point -- and we will continue to work with our provider to ensure that we can continue to provide coverage as our company grows.

With AppEngine, I've never had to migrate a database schema, build a load-balancer, hire a fulltime sysadmin, or even pay for servers that arn't receiving traffic. I don't have to set up a large-scale deployment system, nor spin up a new database server when traffic gets too heavy. AppEngine so far has been remarkably cheap (we're starting to bring in more customers however, so we'll see how long this lasts).

Many of the challenges he mentions come down to thinking about writing a webapp with a longer-term vision in mind. Datastore limitations crop up when you outgrow your first datastore in a standard system; in AppEngine they're properly enumerated and dealt with from day 1. Likewise long-running connections become very tricky to deal with with lots of traffic... this point is a little harder to argue with the recent popularity of asynchronous-io servers, but I think Google is working hard on these limitations. SSL is just annoying; we've had to deal with this by adding an SSL proxy until Google adds SSL support -- but it sounds like Google is pretty close to solving this one (it's been promised by end of year).

Also, AppEngine is written in a very high-level way; should you reach a point where AppEngine no longer makes sense, it is amazingly easy to transition over to another system (as the OP apparently found out; I would give more credit to the design patterns inherent in the AppEngine APIs than 'TDD driven development'). Tornado, webpy, etc have virtually the same interface as AppEngine's webapp framework.

There are definitely tradeoffs when choosing AppEngine as a production backend right now, and its certainly not the right solution for every problem... but for many people, us included, its been a pretty large net benefit for our startup. Google is actively improving the system, and I expect many of these problems will go away in the next 6 months or so.

Interestingly, multi-perspective push-broom images is essentially how the street-view team got started.