1

2

3

4

5

6

7

8

9

10

11

12

1

2

3

4

5

6

1

2

3

4

1

2

3

1

2

1

Lightweight, only 0,5 Kb gzipped

No unnecessary div nesting

Based on CSS Grid

Responsive

12 column system

Simple syntax

Simple naming system

five

seven

nine

three

four

two

two

four

You can also merge rows

four

four

four

four

four

four

1

2

3

4

1

2

3

4

5

6

README.md

povray -W960 -H720 scene01.pov
povray -W960 -H720 scene02.pov
povray -W960 -H720 scene03.pov
povray -W960 -H720 +A0.0 scene04.pov
povray -W960 -H720 +Q9 +A0.0 +AM2 +R5 -J scene05.pov
povray -W960 -H720 +A0.0 +AM2 scene06.pov
povray -W960 -H720 +A0.0 +AM2 scene07.pov
povray -W960 -H720 +A0.0 scene08.pov
povray -W960 -H720 +A0.0 +AM2 scene09.pov
povray -W960 -H720 +A0.0 scene10.pov
povray -W960 -H720 scene11.pov
povray -W960 -H720 +A0.0 +AM2 scene12.pov
povray -W960 -H720 +A0.0 scene13.pov
povray -W960 -H720 +A0.0 +AM2 scene14.pov
povray -W960 -H720 +A0.0 +AM2 scene15.pov
povray -W960 -H720 +A0.0 +AM2 scene16.pov
povray -W960 -H720 +A0.0 +AM2 scene17.pov
povray -W960 -H720 +A0.0 +AM2 scene18.pov
povray -W960 -H720 +A0.0 scene19.pov
povray -W960 -H720 +A0.0 +AM2 +R5 -J scene20.pov
povray -W960 -H720 +A0.0 +AM2 -J scene21.pov
povray -W960 -H720 +A0.0 +AM2 scene22.pov
povray -W960 -H720 +A0.0 +AM2 -J scene23.pov
povray -W960 -H720 +A0.0 +AM2 scene24.pov
povray -W960 -H720 +A0.1 +AM2 scene25.pov

nullprogram.com/blog/2018/05/01/

So far this year I’ve been bitten three times by compiler edge cases in GCC and Clang, each time catching me totally by surprise. Two were caused by historical artifacts, where an ambiguous specification lead to diverging implementations. The third was a compiler optimization being far more clever than I expected, behaving almost like an artificial intelligence.

In all examples I’ll be using GCC 7.3.0 and Clang 6.0.0 on Linux.

x86-64 ABI ambiguity

The first time I was bit — or, well, narrowly avoided being bit — was when I examined a missed floating point optimization in both Clang and GCC. Consider this function:

doublezero_multiply(doublex){returnx*0.0;}

The function multiplies its argument by zero and returns the result. Any number multiplied by zero is zero, so this should always return zero, right? Unfortunately, no. IEEE 754 floating point arithmetic supports NaN, infinities, and signed zeros. This function can return NaN, positive zero, or negative zero. (In some cases, the operation could also potentially produce a hardware exception.)

As a result, both GCC and Clang perform the multiply:

zero_multiply:xorpdxmm1,xmm1mulsdxmm0,xmm1ret

The -ffast-math option relaxes the C standard floating point rules, permitting an optimization at the cost of conformance andconsistency:

zero_multiply:xorpsxmm0,xmm0ret

Side note: -ffast-math doesn’t necessarily mean “less precise.” Sometimes it will actually improve precision.

Here’s a modified version of the function that’s a little more interesting. I’ve changed the argument to a short:

doublezero_multiply_short(shortx){returnx*0.0;}

It’s no longer possible for the argument to be one of those special values. The short will be promoted to one of 65,535 possible double values, each of which results in 0.0 when multiplied by 0.0. GCC misses this optimization (-Os):

zero_multiply_short:movsxedi,di; sign-extend 16-bit argumentxorpsxmm1,xmm1; xmm1 = 0.0cvtsi2sdxmm0,edi; convert int to doublemulsdxmm0,xmm1ret

Clang also misses this optimization:

zero_multiply_short:cvtsi2sdxmm1,edixorpdxmm0,xmm0mulsdxmm0,xmm1ret

But hang on a minute. This is shorter by one instruction. What happened to the sign-extension (movsx)? Clang is treating thatshort argument as if it were a 32-bit value. Why do GCC and Clang differ? Is GCC doing something unnecessary?

It turns out that the x86-64 ABI didn’t specify what happens with the upper bits in argument registers. Are they garbage? Are they zeroed? GCC takes the conservative position of assuming the upper bits are arbitrary garbage. Clang takes the boldest position of assuming arguments smaller than 32 bits have been promoted to 32 bits by the caller. This is what the ABI specification should have said, but currently it does not.

Fortunately GCC also conservative when passing arguments. It promotes arguments to 32 bits as necessary, so there are no conflicts when linking against Clang-compiled code. However, this is not true for Intel’s ICC compiler: Clang and ICC are not ABI-compatible on x86-64.

I don’t use ICC, so that particular issue wouldn’t bite me, but if I was ever writing assembly routines that called Clang-compiled code, I’d eventually get bit by this.

Floating point precision

Without looking it up or trying it, what does this function return? Think carefully.

intfloat_compare(void){floatx=1.3f;returnx==1.3f;}

Confident in your answer? This is a trick question, because it can return either 0 or 1 depending on the compiler. Boy was I confused when this comparison returned 0 in my real world code.

$ gcc   -std=c99 -m32 cmp.c  # float_compare() == 0
$ clang -std=c99 -m32 cmp.c  # float_compare() == 1

So what’s going on here? The original ANSI C specification wasn’t clear about how intermediate floating point values get rounded, and implementations all did it differently. The C99 specification cleaned this all up and introduced FLT_EVAL_METHOD. Implementations can still differ, but at least you can now determine at compile-time what the compiler would do by inspecting that macro.

Back in the late 1980’s or early 1990’s when the GCC developers were deciding how GCC should implement floating point arithmetic, the trend at the time was to use as much precision as possible. On the x86 this meant using its support for 80-bit extended precision floating point arithmetic. Floating point operations are performed in long double precision and truncated afterward (FLT_EVAL_METHOD == 2).

In float_compare() the left-hand side is truncated to a float by the assignment, but the right-hand side, despite being a float literal, is actually “1.3” at 80 bits of precision as far as GCC is concerned. That’s pretty unintuitive!

The remnants of this high precision trend are still in JavaScript, where all arithmetic is double precision (even if simulated using integers), and great pains have been made to work around the performance consequences of this. Until recently, Mono had similar issues.

The trend reversed once SIMD hardware became widely available and there were huge performance gains to be had. Multiple values could be computed at once, side by side, at lower precision. So on x86-64, this became the default (FLT_EVAL_METHOD == 0). The young Clang compiler wasn’t around until well after this trend reversed, so it behaves differently than the backwards compatible GCC on the old x86.

I’m a little ashamed that I’m only finding out about this now. However, by the time I was competent enough to notice and understand this issue, I was already doing nearly all my programming on the x86-64.

Built-in Function Elimination

I’ve saved this one for last since it’s my favorite. Suppose we have this little function, new_image(), that allocates a greyscale image for, say, some multimedia library.

staticvoid*new_image(size_tw,size_th,intshade){unsignedchar*p=0;if(w==0||h<=SIZE_MAX/w){// overflow?p=malloc(w*h);if(p){memset(p,shade,w*h);}}returnp;}

It’s a static function because this would be part of some slick header library (and, secretly, because it’s necessary for illustrating the issue). Being a responsible citizen, the function even checks for integer overflow before allocating anything.

I write a unit test to make sure it detects overflow. This function should return 0.

/* expected return == 0 */inttest_new_image_overflow(void){void*p=new_image(2,SIZE_MAX,0);return!!p;}

So far my test passes. Good.

I’d also like to make sure it correctly returns NULL — or, more specifically, that it doesn’t crash — if the allocation fails. But how can I make malloc() fail? As a hack I can pass image dimensions that I know cannot ever practically be allocated. Essentially I want to force a malloc(SIZE_MAX), e.g. allocate every available byte in my virtual address space. For a conventional 64-bit machine, that’s 16 exibytes of memory, and it leaves space for nothing else, including the program itself.

/* expected return == 0 */inttest_new_image_oom(void){void*p=new_image(1,SIZE_MAX,0xff);return!!p;}

I compile with GCC, test passes. I compile with Clang and the test fails. That is, the test somehow managed to allocate 16 exibytes of memory, and initialize it. Wat?

Disassembling the test reveals what’s going on:

test_new_image_overflow:xoreax,eaxrettest_new_image_oom:moveax,1ret

The first test is actually being evaluated at compile time by the compiler. The function being tested was inlined into the unit test itself. This permits the compiler to collapse the whole thing down to a single instruction. The path with malloc() became dead code and was trivially eliminated.

Clang correctly determined that the image buffer is not actually being used, despite the memset(), so it eliminated the allocation altogether and then simulated a successful allocation despite it being absurdly large. Allocating memory is not an observable side effect as far as the language specification is concerned, so it’s allowed to do this. My thinking was wrong, and the compiler outsmarted me.

I soon realized I can take this further and trick Clang into performing an invalid optimization, revealing a bug. Consider this slightly-optimized version that uses calloc() when the shade is zero (black). The calloc() function does its own overflow check, sonew_image() doesn’t need to do it.

staticvoid*new_image(size_tw,size_th,intshade){unsignedchar*p=0;if(shade==0){// shortcutp=calloc(w,h);}elseif(w==0||h<=SIZE_MAX/w){// overflow?p=malloc(w*h);if(p){memset(p,color,w*h);}}returnp;}

With this change, my overflow unit test is now also failing. The situation is even worse than before. The calloc() is being eliminated despite the overflow, and replaced with a simulated success. This time it’s actually a bug in Clang. While failing a unit test is mostly harmless, this could introduce a vulnerability in a real program. The OpenBSD folks are so worried about this sort of thing that they’ve disabled this optimization.

Here’s a slightly-contrived example of this. Imagine a program that maintains a table of unsigned integers, and we want to keep track of how many times the program has accessed each table entry. The “access counter” table is initialized to zero, but the table of values need not be initialized, since they’ll be written before first access (or something like that).

structtable{unsigned*counter;unsigned*values;};staticinttable_init(structtable*t,size_tn){t->counter=calloc(n,sizeof(t->counter));if(t->counter){/* Overflow already tested above */t->values=malloc(n*sizeof(t->values));if(!t->values){free(t->counter);return0;// fail}return1;// success}return0;// fail}

This function relies on the overflow test in calloc() for the secondmalloc() allocation. However, this is a static function that’s likely to get inlined, as we saw before. If the program doesn’t actually make use of the counter table, and Clang is able to statically determine this fact, it may eliminate the calloc(). This would also eliminate the overflow test, introducing a vulnerability. If an attacker can control n, then they can overwrite arbitrary memory through that values pointer.

The takeaway

Besides this surprising little bug, the main lesson for me is that I should probably isolate unit tests from the code being tested. The easiest solution is to put them in separate translation units and don’t use link-time optimization (LTO). Allowing tested functions to be inlined into the unit tests is probably a bad idea.

The unit test issues in my real program, which was a bit more sophisticated than what was presented here, gave me artificial intelligence vibes. It’s that situation where a computer algorithm did something really clever and I felt it outsmarted me. It’s creepy to consider how far that can go. I’ve gotten that even from observing AI I’ve written myself, and I know for sure no human taught it some particularly clever trick.

My favorite AI story along these lines is about an AI that learned how to play games on the Nintendo Entertainment System. It didn’t understand the games it was playing. It’s optimization task was simply to choose controller inputs that maximized memory values, because that’s generally associated with doing well — higher scores, more progress, etc. The most unexpected part came when playing Tetris. Eventually the screen would fill up with blocks, and the AI would face the inevitable situation of losing the game, with all that memory being reinitialized to low values. So what did it do?

Just before the end it would pause the game and wait… forever.

A couple of months ago, I launched version 2 of Pwned Passwords. This is a collection of over half a billion passwords which have previously appeared in data breaches and the intention is that they're used as a black list; these are the "secrets" that NIST referred to in their recent guidance:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised.

In other words, once a password has appeared in a data breach and it ends up floating around the web for all sorts of nefarious parties to use, don't let your customers use that password! Now, as I say in the aforementioned blog post (and in the post launching V1 before it), it's not always that black and white and indeed outright blocking every pwned password has all sorts of usability ramifications as well. But certainly, many organisations have taken precisely this approach and have used the service to keep known bad passwords out of their systems.

But I always wondered - what sort of percentage of passwords would this actually block? I mean if you had 1 million people in your system, is it a quarter of them using previously breached passwords? A half? More? What I needed to test this theory was a data breach that contained plain text passwords, had a significant volume of them and it had to be one I hadn't seen before and didn't form part of the sources I used to create the Pwned Passwords list in the first place. (Strictly speaking, I could have used a breach with hashed passwords and used the source Pwned Passwords as a dictionary in a hash cracking exercise, but plain text was always going to be much easier, much faster and would allow me to quickly see which password weren't already in my list.)

And then CashCrate came along:

Of those 6.8M records, 2,232,284 of the passwords were in plain text. The remainder were MD5 hashes, assumedly because they were in the process of rolling over to this hashing algorithm when the breach occurred (although when you have all the source passwords in plain text to begin with, it's kinda weird they didn't just hash all those in one go). So to the big question raised earlier, how many of these were already in Pwned Passwords? Or in other words, how many CashCrate subscribers were using terrible passwords already known to have been breached?

In total, there were 1,910,144 passwords out of 2,232,284 already in the Pwned Passwords set. In other words, 86% of subscribers were using passwords already leaked in other data breaches and available to attackers in plain text.

So, what sort of passwords are we talking about here? All the usual terrible ones you'd expect people to choose which, by order of prevalence in the Pwned Password data set, means passwords like these:

1. 123456
2. 123456789
3. qwerty
4. password
5. 111111
6. 12345678
7. abc123
8. password1
9. 1234567
10. 12345

These are terrible and granted, who knows how far back they date, but as of today you can still sign up with a password of "123456" if you'd like:

You can't use "12345" - that's not long enough - and its appearance in position 10 above likely indicates an even weaker password policy in the past. Obviously, the password criteria is terrible, but I appreciate some people may suggest the nature of the site predisposes people to making terrible password choices (it's a "cash-for-surveys" site).

But I was also interested in some of the more obscure CashCrate passwords that were already in my data set and found ones like these that I've only ever seen once before (I'll substitute several characters in each to protect the source password but still illustrate the point):

1. D*lishmars3an0eei3
2. 20921147_bronzegoddess
3. cookiecocospike3278
4. Jonathan.Evans!@34
5. anchorage alaska
6. nikki i love u
7. i like to have sex

I didn't substitute any characters in the last 3 because I wanted to illustrate that even pass phrases can be useless once exposed. Having a good password isn't enough, uniqueness still matters enormously.

So which passwords weren't in Pwned Passwords already? Predictably, some of the most popular ones were named after the site itself:

1. cashcrate123
2. CashCrate
3. mycashcrate
4. cashcreate
5. cashcrate.com
6. etarchsac

And so on and so forth (the last one makes sense once you think about it). Many of the other most common ones were just outright terrible in other ways, for example number combinations or a person's name followed by a number (some quite unique variants appeared many times over suggesting possible bulk account creation). All of those will go into the next release of Pwned Passwords which will go out once there's a sufficiently large volume of new passwords.

Getting back to the whole point of the service for a moment, traditional password complexity rules are awful and they must die a fiery death:

I wrote last year about how password strength indicators help people make ill-informed choices and clearly based on the tweet above, that's still absolutely true today.

Getting back to the issue of how terrible passwords are and the impact this then has on individuals and organisations alike, one of the big problems I've seen really accelerate over the last year is credential stuffing. In other words, bad guys grabbing huge stashes of username and password pairs from other data breaches and seeing which ones work on totally unrelated sites. I have a much more comprehensive blog post in this in the works and it's a non-trivial challenge I want to devote more time to, but imagine this:

If you're responsible for running a website, how are you going to be resilient against attackers who come to your site with legitimate usernames and passwords of your members?

And just to make things even harder, the site being attacked isn't necessarily viewed as the victim either. Earlier this year, the FTC had this to say:

The FTC's message is loud and clear: If customer data was put at risk by credential stuffing, then being the innocent corporate victim is no defence to an enforcement case. Rather, in the FTC's view companies holding sensitive customer information should be taking affirmative action to reduce the risk of credential stuffing.

That's a hard challenge and the solution is non-trivial too. Again, I've got something more comprehensive in draft and I'll definitely come back to that but for now, this is a great start:

I like this because it is trivial! It's not the whole picture in terms of defences, but it's a great start. I don't know if EVE Online would have 86% of members using known breached passwords (it's not exactly "cash-for-surveys", but then again, it's also used by a lot of kids), but I do know that it would still be a statistically significant numbers. (Incidentally, this should go live on EVE Online about the same time I plan to publish this blog post.)

As I come across more plain text data breaches (which is inevitable), I'll do the same sanity check again. For now, I've taken the 322,140 passwords not already in Pwned Passwords, distilled it down to 307,016 unique ones and queued those up for version 3 of the password list. While you're waiting for that one, it might be worth thinking about how many subscribers of your own service are using a previously seen password because if it's even a fraction of the CashCrate number, that's rather worrying.

Kernel features like seccomp filters can provide better isolation between the application and host kernel, but they require the user to create a predefined whitelist of system calls. In practice, it’s often difficult to know which system calls will be required by an application beforehand. Filters also provide little help when a vulnerability is discovered in a system call that your application requires.

Existing VM-based container technology

Kata containers is an open-source project that uses stripped-down VMs to keep the resource footprint minimal and maximize performance for container isolation. Like gVisor, Kata contains an Open Container Initiative (OCI) runtime that is compatible with Docker and Kubernetes.

Sandboxed containers with gVisor

"Secure workloads are a priority for the industry. We are encouraged to see innovative approaches like gVisor and look forward to collaborating on specification clarifications and making improvements to joint technical components in order to bring additional security to the ecosystem."
— Samuel Ortiz, member of the Kata Technical Steering Committee and Principal Engineer at Intel Corporation

“Hyper is encouraged to see gVisor’s novel approach to container isolation. The industry requires a robust ecosystem of secure container technologies, and we look forward to collaborating on gVisor to help bring secure containers into the mainstream.”
— Xu Wang, member of the Kata Technical Steering Committee and CTO at Hyper.sh

Integrated with Docker and Kubernetes

The runsc runtime is interchangeable with runc, Docker's default container runtime. Installation is simple; once installed it only takes a single additional flag to run a sandboxed container in Docker:

$ docker run --runtime=runsc hello-world
$ docker run --runtime=runsc -p 3306:3306 mysql

The runsc runtime can run sandboxed pods in a Kubernetes cluster through the use of either the cri-o or cri-containerd projects, which convert messages from the Kubelet into OCI runtime commands.

gVisor implements a large part of the Linux system API (200 system calls and counting), but not all. Some system calls and arguments are not currently supported, as are some parts of the /proc and /sys filesystems. As a result, not all applications will run inside gVisor, but many will run just fine, including Node.js, Java 8, MySQL, Jenkins, Apache, Redis, MongoDB, and many more.

Getting started

If you’re at KubeCon in Copenhagen join us at our booth for a deep dive demo and discussion.

Also check out an interview with the gVisor PM to learn more.

Starting in 1945, when he was 17 and living in the Bronx, Stanley Kubrick worked as a New York-based photographer for Look magazine. He joined the staff full time in October 1946, and he quit in August 1950. “By the time I was 21 I had four years of seeing how things worked in the world,” Kubrick told an interviewer in 1972. “I think if I had gone to college I would never have been a director.”

The postwar years were the heyday of the popular American pictorial magazines, with Life and Look leading the charge. Life was the classier of the two, adopting an international scope and employing a heady lineup of photographers, including Henri Cartier-Bresson and W. Eugene Smith. Look, which went out of business in 1971, was more provincial, focusing most of its attention on American pursuits and problems, and hiring photographers who were highly professional but rarely inspired.

The Look archive resides at the Museum of the City of New York, where an exhibition titled “ Through a Different Lens: Stanley Kubrick Photographs,” opens on May 3. The show and an accompanying catalog published by Taschen look at what is essentially Kubrick before he became Kubrick.

Unless they were recording news events, photographers for the picture magazines were hobbled by a crippling constraint. Their photos were illustrating a preconceived story that had been formulated by the editors. The possibilities for discovery were limited.

The topics that Kubrick explored are chestnuts so old that they smell a little moldy. Lovers embracing on a park bench as their neighbors gaze ostentatiously elsewhere. Patients anxiously awaiting their doctors appointment. Boxing hopefuls in the ring. Celebrities at home. Pampered dogs in the city. It probably helped that Stan Kubrick, as he was known at that time, was just a kid, so instead of inducing yawns, these magazine perennials struck him as novelties, and he in turn brought something fresh to them.

Posted: May 2, 2018

Benchmark results

DAWNBench is a Stanford University project designed to allow different deep learning methods to be compared by running a number of competitions. There were two parts of the Dawnbench competition that attracted our attention, the CIFAR 10 and Imagenet competitions. Their goal was simply to deliver the fastest image classifier as well as the cheapest one to achieve a certain accuracy (93% for Imagenet, 94% for CIFAR 10).

In the CIFAR 10 competition our entries won both training sections: fastest, and cheapest. Another fast.ai student working independently, Ben Johnson, who works on the DARPA D3M program, came a close second in both sections.

In the Imagenet competition, our results were:

• Fastest on publicly available infrastructure, fastest on GPUs, and fastest on a single machine (and faster than Intel’s entry that used a cluster of 128 machines!)
• Lowest actual cost (although DAWNBench’s official results didn’t use our actual cost, as discussed below).

Overall, our findings were:

• Algorithmic creativity is more important than bare-metal performance
• Pytorch, developed by Facebook AI Research and a team of collaborators, allows for rapid iteration and debugging to support this kind of creativity
• AWS spot instances are an excellent platform for rapidly and inexpensively running many experiments.

In this post we’ll discuss our approach to each competition. All of the methods discussed here are either already incorporated into the fastai library, or are in the process of being merged into the library.

Super convergence

fast.ai is a research lab dedicated to making deep learning more accessible, both through education, and developing software that simplifies access to current best practices. We do not believe that having the newest computer or the largest cluster is the key to success, but rather utilizing modern techniques and the latest research with a clear understanding of the problem we are trying to solve. As part of this research we recently developed a new library for training deep learning models based on Pytorch, called fastai.

Over time we’ve been incorporating into fastai algorithms from a number of research papers which we believe have been largely overlooked by the deep learning community. In particular, we’ve noticed a tendency of the community to over-emphasize results from high-profile organizations like Stanford, DeepMind, and OpenAI, whilst ignoring results from less high-status places. One particular example is Leslie Smith from the Naval Research Laboratory, and his recent discovery of an extraordinary phenomenon he calls super convergence. He showed that it is possible to train deep neural networks 5-10x faster than previously known methods, which has the potential to revolutionize the field. However, his paper was not accepted to an academic publishing venue, nor was it implemented in any major software.

Within 24 hours of discussing this paper in class, a fast.ai student named Sylvain Gugger had completed an implementation of the method, which was incorporated into fastai and he also developed an interactive notebook showing how to experiment with other related methods too. In essence, Smith showed that if we very slowly increase the learning rate during training, whilst at the same time decreasing momentum, we can train at extremely high learning rates, thus avoiding over-fitting, and training in far fewer epochs.

Such rapid turnaround of new algorithmic ideas is exactly where Pytorch and fastai shine. Pytorch allows for interactive debugging, and the use of standard Python coding methods, whilst fastai provides many building blocks and hooks (such as, in this case, callbacks to allow customization of training, and fastai.sgdr for building new learning rate annealing methods). Pytorch’s tensor library and CUDA allow for fast implementation of new algorithms for exploration.

We have an informal deep learning study group (free for anyone to join) that meets each day to work on projects together during the course, and we thought it would be interesting to see whether this newly contributed code would work as well as Smith claimed. We had heard that Stanford University was running a competition called DAWNBench, which we thought would be an interesting opportunity to test it out. The competition finished just 10 days from when we decided to enter, so timing was tight!

CIFAR 10

Both CIFAR 10 and Imagenet are image recognition tasks. For instance, imagine that we have a set of pictures of cats and dogs, and we want to build a tool to separate them automatically. We build a model and then train it on many pictures so that afterwards we can classify dog and cat pictures we haven’t seen before. Next, we can take our model and apply it to larger data sets like CIFAR, a collection of pictures of ten various objects like cats and dogs again as well as other animals/vehicles, for example frogs and airplanes. The images are small (32 pixels by 32 pixels) and so this dataset is small (160MB) and easy to work with. It is, nowadays, a rather under-appreciated dataset, simply because it’s older and smaller than the datasets that are fashionable today. However, it is very representative of the amount of data most organizations have in the real world, and the small image size makes it both challenging but also accessible.

When we decided to enter the competition, the current leader had achieved a result of 94% accuracy in a little over an hour. We quickly discovered that we were able to train a Resnet 50 model with super-convergence in around 15 minutes, which was an exciting moment! Then we tried some different architectures, and found that Resnet 18 (in its preactivation variant) achieved the same result in 10 minutes. We discussed this in class, and Ben Johnson independently further developed this by adding a method fast.ai developed called “concat pooling” (which concatenates max pooling and average pooling in the penultimate layer of the network) and got down to an extraordinary 6 minutes on a single NVIDIA GPU.

In the study group we decided to focus on multi-GPU training, in order to get the fastest result we could on a single machine. In general, our view is that training models on multiple machines adds engineering and sysadmin complexity that should be avoided where possible, so we focus on methods that work well on a single machine. We used a library from NVIDIA called NCCL that works well with Pytorch to take advantage of multiple GPUs with minimal overhead.

Most papers and discussions of multi-GPU training focus on the number of operations completed per second, rather than actually reporting how long it takes to train a network. However, we found that when training on multiple GPUs, our architectures showed very different results. There is clearly still much work to be done by the research community to really understand how to leverage multiple GPUs to get better end-to-end training results in practice. For instance, we found that training settings that worked well on single GPUs tended to lead to gradients blowing up on multiple GPUs. We incorporated all the recommendations from previous academic papers (which we’ll discuss in a future paper) and got some reasonable results, but we still weren’t really leveraging the full power of the machine.

In the end, we found that to really leverage the 8 GPUs we had in the machine, we actually needed to give it more work to do in each batch—that is, we increased the number of activations in each layer. We leveraged another of those under-appreciated papers from less well-known institutions: Wide Residual Networks, from Université Paris-Est, École des Ponts. This paper does an extensive analysis of many different approaches to building residual networks, and provides a rich understanding of the necessary building blocks of these architectures.

Another of our study group members, Brett Koonce, started running experiments with lots of different parameter settings to try to find something that really worked well. We ended up creating a “wide-ish” version of the resnet-34 architecture which, using Brett’s carefully selected hyper-parameters, was able to reach the 94% accuracy with multi-GPU training in under 3 minutes!

AWS and spot instances

We were lucky enough to have some AWS credits to use for this project (thanks Amazon!) We wanted to be able to run many experiments in parallel, without spending more credits than we had to, so study group member Andrew Shaw built out a python library which would allow us to automatically spin up a spot instance, set it up, train a model, save the results, and shut the instance down again, all automatically. Andrew even set things up so that all training occurred automatically in a tmux session so that we could log in to any instance and view training progress at any time.

Based on our experience with this competition, our recommendation is that for most data scientists, AWS spot instances are the best approach for training a large number of models, or for training very large models. They are generally about a third of the cost of on-demand instances. Unfortunately, the official DAWNBench results do not report the actual cost of training, but instead report the cost based on an assumption of on-demand pricing. We do not agree that this is the most useful approach, since in practice spot instance pricing is quite stable, and is the recommended approach for training models of this type.

Google’s TPU instances (now in beta) may also a good approach, as the results of this competition show, but be aware that the only way to use TPUs is if you accept lock-in to all of:

• Google’s hardware (TPU)
• Google’s software (Tensorflow)
• Google’s cloud platform (GCP).

More problematically, there is no ability to code directly for the TPU, which severely limits algorithmic creativity (which as we have seen, is the most important part of performance). Given the limited neural network and algorithm support on TPU (e.g. no support for recurrent neural nets, which are vital for many applications, including Google’s own language translation systems), this limits both what problems you can solve, and how you can solve them.

AWS, on the other hand, allows you to run any software, architecture, and algorithm, and you can then take the results of that code and run them on your own computers, or use a different cloud platform. The ability to use spot instances also means you we were able to save quite a bit of money compared to Google’s platform (Google has something similar in beta called “preemptible instances”, but they don’t seem to support TPUs, and automatically kill your job after 24 hours).

For single GPU training, another great option is Paperspace, which is the platform we use for our new courses. They are significantly less complex to set up than AWS instances, and have the whole fastai infrastructure pre-installed. On the other hand, they don’t have the features and flexibility of AWS. They are more expensive than AWS spot instances, but cheaper that AWS on-demand instances. We used a Paperspace instance to win the cost category of this competition, with a cost of just $0.26.

Half precision arithmetic

Another key to fast training was the use of half precision floating point. NVIDIA’s most recent Volta architecture contains tensor cores that only work with half-precision floating point data. However, successfully training with this kind of data has always been complex, and very few people have shown successful implementations of models trained with this data.

NVIDIA was kind enough to provide an open-source demonstration of training Imagenet using half-precision floating point, and Andrew Shaw worked to incorporate these ideas directly into fastai. We’ve now gotten it to a point where you simply write learn.half() in your code, and from there on all the necessary steps to train quickly and correctly with half-precision floating point are automatically done for you.

Imagenet

Imagenet is a different version of the same problem as CIFAR 10, but with larger images (224 pixels, 160GB) and more categories (1000). Smith showed super convergence on Imagenet in his paper, but he didn’t reach the same level of accuracy as other researchers had on this dataset. We had the same problem, and found that when training with really high learning rates that we couldn’t achieve the required 93% accuracy.

Instead, we turned to a method we’d developed at fast.ai, and teach in lessons 1 & 2 of our deep learning course: progressive resizing. Variations of this technique have shown up in the academic literature before (Progressive Growing of GANs and Enhanced Deep Residual Networks) but have never to our knowledge been applied to image classification. The technique is very simple: train on smaller images at the start of training, and gradually increase image size as you train further. It makes intuitive sense that you don’t need large images to learn the general sense of what cats and dogs look like (for instance), but later on when you’re trying to learn the difference between every breed of dog, you’ll often need larger images.

Many people incorrectly believe that networks trained on one size of images can’t be used for other sizes. That was true back in 2013 when the VGG architecture was tied to one specific size of image, but hasn’t been true since then, on the whole. One problem is that many implementations incorrectly used a fixed-size pooling layer at the end of the network instead of a global/adaptive pooling layer. For instance none of the official pytorch torchvision models use the correct adaptive pooling layer. This kind of issue is exactly why libraries like fastai and keras are important—libraries built by people who are committed to ensuring that everything works out-of-the-box and incorporates all relevant best practices. The engineers building libraries like pytorch and tensorflow are (quite rightly) focused on the underlying foundations, not on the end-user experience.

By using progressive resizing we were both able to make the initial epochs much faster than usual (using 128x128 images instead of the usual 224x224), but also make the final epochs more accurate (using 288x288 images for even higher accuracy). But performance was only half of the reason for this success; the other impact is better generalization performance. By showing the network a wider variety of image sizes, it helps it to avoid over-fitting.

A word on innovation and creativity

I’ve been working with machine learning for 25 years now, and throughout that time I’ve noticed that engineers are drawn to using the biggest datasets they can get, on the biggest machines they can access, like moths flitting around a bright light. And indeed, the media loves covering stories about anything that’s “biggest”. The truth though is that throughout this time the genuine advances consistently come from doings things differently, not doing things bigger. For instance, dropout allows us to train on smaller datasets without over-fitting, batch normalization lets us train faster, and rectified linear units avoid gradient explosions during training; these are all examples of thoughtful researchers thinking about doing things differently, and allowing the rest of us to train better networks, faster.

I worry when I talk to my friends at Google, OpenAI, and other well-funded institutions that their easy access to massive resources is stifling their creativity. Why do things smart when you can just throw more resources at them? But the world is a resource-constrained place, and ignoring that fact means that you will fail to build things that really help society more widely. It is hardly a new observation to point out that throughout history, constraints have been drivers of innovation and creativity. But it’s a lesson that few researchers today seem to appreciate.

Worse still are the people I speak to that don’t have access to such immense resources, and tell me they haven’t bothered trying to do cutting edge research because they assume that without a room full of GPUs, they’ll never be able to do anything of value. To me, they are thinking about the problem all wrong: a good experimenter with a slow computer should always be able to overtake a poor experimenter with a fast one.

We’re lucky that there folks like the Pytorch team that are building the tools that creative practitioners need to rapidly iterate and experiment. I hope that seeing that a small non-profit self-funded research lab and some part-time students can achieve these kinds of top-level results can help bring this harmful myth to an end.

We are excited to announce that starting May 2nd, 2018, you will be able to test and deploy your open source and private projects on travis-ci.com.

We’re proud to support open source and we believe this change will give you more flexible workflows and a better overall experience. In addition, our integration with GitHub is moving to GitHub Apps. This allows us to offer improved security and paves the way for some exciting new features.

Back in the Early Days…

We created a separate platform for private repositories on travis-ci.com as a way to differentiate our subscription offering from our community-sponsored open source offering. We also thought it would be a helpful barrier to allow us to trial new features on open source.

Over time we found two platforms lead to confusion for people using travis-ci.org extensively, or together with travis-ci.com. Not to mention, it is tricky for our support and engineering teams to keep everything updated in concert.

However, when we decided to move our GitHub integration to GitHub Apps at the beginning of this year, we realized it was a great opportunity to dive into merging travis-ci.org and travis-ci.com into a single platform. Our new Integration would be the first service built specifically for the new combined platform. With the first release of this process complete, we’re thrilled to share everything we’ve been building!

GitHub Apps Integration

Moving to GitHub Apps has been the biggest change to our integration to date, and we’re looking forward to the flexibility it brings. This creates the foundation for us to remove the repo-scoped OAuth login token, which is a common request, so eventually you will be able to grant us access to only the repositories you want to test on our platform.

The new integration brings reliability and stability to how Travis CI communicates with GitHub. This means that as developers change teams within organizations, or repository ownership changes, Travis CI will continue to run builds seamlessly.

In addition, GitHub Apps makes it easier for users to sign up with us through the GitHub Marketplace, which provides a simple billing solution across the GitHub ecosystem.

Here’s How to Jump In!

Adding New Repositories to Travis CI

If you’re activating a new repository – either public or private – on Travis CI, please use travis-ci.com. You’ll be able to take advantage of our newest features, and share additional concurrency between open source and private repositories.

Repositories Already Using travis-ci.org

Existing repositories and their build histories will stay on travis-ci.org for the moment. We will have further updates soon on how to migrate your build history from travis-ci.org to travis-ci.com. Read more on how this will work for your existing Open Source repositories in the docs.

Repositories Already Using travis-ci.com

You can switch over to GitHub Apps on your account page on travis-ci.com. Log in, click the “Activate and Migrate” button, and select the repos you want to move over. Happy building!

New Travis CI Users

Welcome to Travis CI! Go ahead and sign up at travis-ci.com. You will be able to use the GitHub Apps Integration right away, and all of your repositories will be in one place. This is the best time to get started!

Current Travis CI Users

You can continue to use both your travis-ci.org and travis-ci.com accounts as usual for now. Over the next several months, we’ll be migrating all travis-ci.org repositories and customers to travis-ci.com. Though this will not happen right away, you can go ahead and read more about what to expect in the docs.

Thank You!

We’re really excited for you and your team to start testing open source and private repositories together.

We also want to send a huge shout out to GitHub for all of their work and help making this integration possible!

If you have questions, comments, thoughts or feedback, please let us know at support@travis-ci.com.

Happy Building!

Josh Kalderimis VP of Product

README.md

git clone https://github.com/YadiraF/PRNetcd PRNet

Note, that only Microsoft Office packages Excel, Word and PowerPoint are in active developement. The other packages are proof-of-concept examples only.

The CAWT package is copyrighted by Paul Obermeier and distributed under the 3-clause BSD license.

The sources and distribution packages are available on SourceForge.
CAWT is also available via BAWT (Build Automation With Tcl).

CAWT relies on several other Tcl packages. See the table in chapter 1.2 of the User manual for links to these packages to get their license information.

Slideshow

• SlideshowIvan Sigal, Footbridge, Gilani Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Gilani Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Gilani Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Tracks under Karachi Port Trust Interchange, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Furniture Market on the Tracks near the Lyari River, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Laminating Paper, along the Tracks near the Lyari River, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Interior, Depot Hill Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Depot Hill Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Switching House near Depot Hill Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Footbridge, Karachi University Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Manghopir Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Sameer Snooker Club, under Rashid Minhas Road, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Sinbad’s Wonderland, Rashid Minhas Road, Karachi Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Footbridge near Orangi Town Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Furniture Market, Orangi Town Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Furniture Market, Orangi Town Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Handmade Trampoline, Orange Town Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Informal Housing, Orangi Town Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Platform, North Nazimabad Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Handmade Ferris Wheel, North Nazimabad Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Footbridge, North Nazimabad Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Tracks near Urdu College Halt, Karachi Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Informal Housing, Urdu College Halt, Karachi Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Market, Shireen Jinnah Colony, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Informal Housing, near Depot Hill Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Wall across Railway Bridge, Orangi Town Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Tracks from Johar Mor Bridge, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Footbridge, Wazir Mansion Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Platform, Karachi City Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Platform, Karachi City Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Footbridge, Karachi City Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

• SlideshowIvan Sigal, Tracks from Kala Pul Road near Karachi Cantonment Station, Karachi, Pakistan. Still image from KCR, 2014-2017, nine-channel multimedia installation.

The Karachi Circular Railway is 43.3, ¹ or 43.12, ² or 44, ³ 48, ⁴ or 50 ⁵ kilometers long. It started in 1964, or 1969. It shut down officially in 1999, or a train still runs twice a day on part of the line. ⁶

The city’s transit system is run by the KMC, the CDGK, the KDA, the KTC, the KMTC, by the KUTC, by Karachi’s Mass Transit Department, by Pakistan Railways, or by the Karachi Development Company Ltd. ⁷ It follows the logic of the Karachi Master Plan, ⁸ the KMTP, ⁹ or the UTS. ¹⁰ Perhaps one day it will follow the KTIP, ¹¹ and the KMTMP, ¹² with the support of the MPGO. ¹³ It will be overseen by the KTMA, ¹⁴ or the SMTA, ¹⁵ or the PTA.

A high-level committee has been formed for the revival of the project. ¹⁶

There will be four rapid bus lines, ¹⁷ or five, ¹⁸ or six. ¹⁹ They will be orange, yellow, red, green, blue, and maybe purple. Or brown. Each line will be financed separately, by the government of Pakistan, ²⁰ the Asian Development Bank, ²¹ a Chinese electric company, ²² a private real estate company, ²³ Bahria Town, ²⁴ or the government of Sindh province. ²⁵ They will have separate ticketing systems, or they will share a unified brand and ticket. Development is proceeding smoothly, or work will be stopped for lack of funding, or political interference; but homes have already been demolished and utility lines relocated. ²⁶ The buses will run on elevated tracks, or at grade. ²⁷ There will be one circular light rail, or another line intersecting it, ²⁸ or there will be two metro rail lines and a circular railway. ²⁹ There will be a cheaper system developed by Pakistani Railways with existing rolling stock. ³⁰ Municipal authorities will own and operate the transit system, or Pakistani Railways will retain control. It will be managed by a private contractor, or it won’t. Buses, minibuses, rickshaws, and Qingqis will run on compressed natural gas, or diesel, or both, or neither. ³¹

Karachi has a population of 18 million, or 20 million. It has a population of 21 million, ³² 22 million, ³³ or 23 million. It has a population of nearly 24 million. ³⁴ It was the fastest growing city in the second half of the 20th century. ³⁵ Now it is the fastest growing city in the world. ³⁶ If it continues to grow at this rate, it will be the second largest city in the world, and the largest without mass transit. ³⁷

Karachi is already one of the largest metro areas with no mass transit. ³⁸ It is one of the few megacities with no mass transit. ³⁹ 4.5 percent of vehicles on the road are public transport, of which 0.85 percent are buses. 42 percent of passengers use public transport. Public transport in Karachi is organized through the licensing of routes to private carriers. ⁴⁰

Karachi has 9,000 buses. ⁴¹ It has 12,399 buses, ⁴² but only 9,527 are running. ⁴³ It has 6,457 buses and 2,715 contract carriages, buses, and luxury coaches. ⁴⁴ There are 1,800 contract buses and 1,800 route buses. ⁴⁵ A few years ago it had 22,313 buses. ⁴⁶

To rebuild the Karachi Circular Railway, 5,000 households will need to be relocated. ⁴⁷ 23,000 people will have to move. 6,500 houses will be affected, with an average of 10 people in each. ⁴⁸ 2,500 homes and 4,500 families will be displaced. ⁴⁹“Squatters” occupy 20 percent of the land along the route. ⁵⁰ They will be relocated to Murad Goth on the far outskirts of the city, or to other land owned by Pakistani Railways, or they will be paid cash equivalent to the fair market value of their properties and left to find their own accommodations.

72 percent of the encroachment on Pakistan Railways land is by industrial facilities, government institutions, and international businesses. Or 78 percent. ⁵¹ No one knows how they will be moved, or compensated, or anything else.

Ivan Sigal, Traffic Near North Nazimabad Station, Karachi, Pakistan. Video assemblage from KCR, 2014-2017, nine-channel multimedia installation.

Karachi has long been a city of immigrants and refugees. It was a safe harbor for the Mujahirs who left India after Partition, for rural Pakistanis who moved here during the Green Revolution, for refugees who fled civil wars in Bangladesh and Afghanistan, and for Pashto communities escaping 21st century counter-terror wars. They all needed housing and transport. In the 1960s, the city planned huge new neighborhoods in the exurbs and designed mass transit to connect them to the center. The Karachi Circular Railway was a key part of that infrastructure. Trains ran every half-hour, and the tickets were cheap enough that the poor could ride alongside the middle class.

The new railway buildings were designed in a modernist style by the Swedish-British firm of Marz, Reddell, Vatten. The simply drawn rail stations, switching houses, platforms, fences, outbuildings, and elegant concrete footbridges made visible the connection between a building and its purpose. Modernism promised replication — of forms, of systems, of industrial processes — and offered a grammar with which to structure the topography, to make the city legible to itself.

Modernism offered a grammar with which to structure the topography, to make the city legible to itself.

This vision of a rational city, growing according to the wisdom of its planners and in the service of building a nation, was eventually overwhelmed by successive waves of migration, as settlers’ need for housing outpaced the state’s capacity to plan. Many arrivals ended up in katchi abadi— literally, raw settlements. These informal housing developments were often built on state land in collusion with government administrators, development authorities, and political parties. Katchi abadi filled in, overspilled, and redrew the grids of planned communities, and spread along railways and other transit corridors.

At its peak in the mid-1970s, the Karachi Circular Railway served 6 million passengers annually, but by the end of its first decade, the system was already in decline. ⁵² High maintenance costs and unstable funding prevented investments in the infrastructure necessary to keep up with population growth. There was no grade separation at many street intersections, and traffic congestion slowed the train as the city grew, which in turn led to lower ridership and a downward spiral in revenue. These pressures continued through the 1980s and 1990s, as the railway also faced a rash of transit crime, ticketless riders, and competition with new transport options. By 1998 the KCR was making only twelve trips a day, and traveling no faster than a walking pace in some sections. The next year it was shut down.

In the two decades since, there have been sporadic efforts to rebuild the railway. Most plans have included an upgrade to the train stock, new track technology, and a substantial overhaul of street crossings, with stretches of elevated track. The Karachi Urban Transport Corporation was set up to consolidate these efforts, and at various times it secured commitments for billions of dollars from Japanese and Chinese development agencies and the Pakistani government. But plans have been impeded by political disagreements and community resistance. One problem is the need to reclaim land from the people and organizations who now occupy it, many of whom have political power and wealth. An even greater challenge is resolving political fights over the allocation of resources among the city, provincial, and federal governments.

Every year, planners confidently state a new date for groundbreaking, a new financial package, a new authority to appropriate land and build modern light rail. Backup plans call for Pakistan Railways to simply clear the land and run the existing trains on renovated tracks.

For now, the rail line is a faint trace, overgrown with brush, unseen but present in the city center. Neighborhoods grow into and around the corridor, and people adopt the open space for their own use. It is a place for discarding trash and using the toilet, for poaching birds and hunting scorpions in the fields of thorn bush. Settlers live on the station platforms, in structures made of canvas, tarp, and stacked wood. Others have repurposed the station buildings as squats, using sandbags and bricks to close off doorways and windows. There are vegetable plots, playing fields, and graveyards.

In Baloch Colony, the railway is lined with open-air barbers and tailors. At Rashid Minhas Road, men and boys play billiards under the overpass. Children play cricket by the port. In many areas, the railway corridor is a shortcut for walkers and motorbikes escaping the congested streets. Near the Lyari River, a large furniture market sits directly on the tracks, and small manufacturers build and repair everything from sofa sets to chicken coops. In Shireen Jinnah Colony, vendors sell oranges, bananas, and mangos, and push their fruit carts off the tracks when freight trains crawl through several times a day. Here, too, you can buy firewood, livestock, dry goods, and cheerful plastic toys.

Many people in Karachi still hope for a rebuilt and renewed circular commuter railway, but the train’s boosters have repeatedly failed to secure political backing and financing. Alternative strategies such as dedicated bus lines may be cheaper and more effective. Whatever the future holds, efforts to reorder urban transport in Karachi will be only part of a larger transformation of the city’s contested spaces. Any new infrastructure will have to be secured by a social compact that recognizes public transport as an accepted, welcome, and safe feature of the city.

Cite

Autism is challenging to diagnose, especially early in life. A new study in the journal Scientific Reports shows that inexpensive EEGs, which measure brain electrical activity, accurately predict or rule out autism spectrum disorder (ASD) in infants, even in some as young as 3 months.

May 02, 2018 · by Lukas Larsson .

example({ok, Val}) -> {ok, Val}.

example({ok, Val} = Tuple) -> Tuple.

It's a promise that seems almost too good to be true: super-fast internet that's cheap, and free of the contracts and hassles that come with major service providers.

That's not a pipe dream for Brian Hall, it's his goal.

The lead volunteer behind the community group NYC Mesh aims to bring affordable internet with lightning-quick downloads to everyone in New York, one building at a time.

"Our typical speeds are 80 to 110 megabits a second," Hall says, pointing out that streaming something like Netflix only requires about 5 Mbps.

The worksite is one of the group's latest customers, a converted warehouse that houses a video production company. The regular commercial internet providers were going to charge tens of thousands of dollars to get them online.

NYC Mesh took on the job for a small installation fee of a few hundred dollars and a monthly donation.

Mesh networks explained

So what is a mesh network?

Picture a spiderweb of wireless connections. The main signal originates from what's called the Supernode. It's a direct plugin to the internet, via an internet exchange point — the same place Internet Service Providers get their connection.

The signal from the supernode, sent out wirelessly via an antenna, covers an area of several kilometres.

From there, a mesh of smaller antennas spread out on rooftops or balconies receive that signal. They're connected to Wi-Fi access points that allow people to use the internet.

Each supernode can connect thousands of users.

And the access points talk to the others around them, so if one goes down for some reason the rest still work.

"Mesh networks are an alternative to standard ISP hookups. You're not provided with an internet connection through their cable, but through — in our case —Wi-Fi networks," says Jason Howard, a programmer and actor who's helping with the latest installation.

NYC Mesh bought an industrial-strength connection to the internet right at an Internet Exchange Point (IXP), in this case a futuristic-looking tower in downtown Manhattan. It's the same place that internet service providers (ISPs) like Verizon and Spectrum connect to the internet, accessing massive amounts of wired bandwidth.

From there it beams out and receives Wi-Fi signals, connecting to receivers on rooftops spread through the East Village and Chinatown, and across the river into parts of Brooklyn.

Myth of the ISP

Zach Giles is one of the brains behind the network and one its busiest volunteers. When he's not working his day job in finance, he's maintaining the supernode. The rooftop has become his second office.

He's a mesh network evangelist who says most people don't realize they don't need to rely on traditional ISPs to get online.

"That's the myth of the ISP," Giles says in between installing another antenna.

Staring out over a city of millions with so many potential users, Giles says he wishes he could shout out that message for everyone to hear that there are other — and cheaper — ways to connect to the internet than corporate ISPs.

One person who has heard the message is Jessica Marshall. A mechanical engineer, she's been watching NYC Mesh's growth for a while.

Marshall says she's driven by, "the fact that I didn't have to rely on a gigantic company that's headquartered somewhere else — that's run by people who don't care about me or the internet necessarily, but profits."

She adds that, "You can build your own internet [connection] and have control over it."

Net neutrality

Since 2013, NYC Mesh has installed 154 antennas around New York, offering service to thousands of people.

When net neutrality rules in the U.S. were repealed in December, interest in NYC Mesh spiked dramatically. The group went from 500 requests for installation all of last year to 1,300 so far this year.

The fear drawing some new users to NYC Mesh is that, with net neutrality rules gone — the Federal Communications Commission in the U.S. took them off the books on Monday — ISPs have the ability to block or slow down access to various websites or potentially charge for access to certain sites.

NYC Mesh promises they won't slow down internet speeds or limit access to sites, and will never store, track or monitor personal data.

The ability to get around the big internet providers gives a Robin Hood-esque feel to the volunteers at NYC Mesh, many of whom, like Howard, admit to a rebellious streak.

Howard says he doesn't see himself as a revolutionary — "maybe just anti-authority," he adds with a smile.

"The big companies would have you think that there's no option than them, especially in New York City," Howard says. "It's so refreshing to come across this ability to do something else as an alternative."

Still niche

But for all its growth, NYC Mesh is still very much in its infancy, says Motherboard science writer Kaleigh Rogers.

"It's still such a small sort of niche community."

She says mesh networks challenge the public's sense of how the internet operates.

Rogers does point out, however, that one of the barriers to entry for mesh customers can be the technical requirements.

Unlike signing up with a commercial ISP, which just involves a phone call to a major provider, a mesh network requires customers to invest a bit more time and effort.

"You have to understand a little bit about the technical aspects of it," Rogers says.

"So I think people are a little intimidated. And it's just not as widely known — we don't have any really good 'use' cases here in North America that show how active and how nice [mesh] can be if you actually have enough users."

While there are mesh networks dotting the U.S., she says the best working example of what mesh technology can do is in Spain. Guifi.net has more than 34,000 nodes covering an area of roughly 50,000 square kilometres across the Catalonia region.

Inside the mesh

Back in New York, most of NYC Mesh's users are clustered around the first supernode in downtown Manhattan, in Chinatown and the Lower East Side. The surge in interest has allowed the group to build a second supernode in Brooklyn, expanding coverage there.

Linda Justice has been using the network for about a year and a half. She read about the project in a local newspaper and was instantly drawn to the idea of a community-driven network.

She adds that the difference in cost is remarkable. She gives NYC Mesh a donation of $20 a month, when she can. Justice was paying close to $100 a month with her old provider.

"It's worth it to take the time and learn about it," Justice says.

Bridging the digital divide

Affordability is one feature of mesh networks, another is resiliency.

Since the routers are interconnected, if one node goes down, the others can pick up the slack. So even if the main connection to the internet is lost during a power outage, the mesh network can maintain connectivity among its access points for basic functions like text messaging.

The U.S. government is now funding mesh networks in various neighbourhoods to prepare for the next storm.

In Harlem, Clayton Banks jumped at the chance to provide his area with one. As head of community tech group Silicon Harlem, he sees the potential reaching far beyond the initial rollout to local businesses.

"We're going to help your kids learn a little bit more about technology. We're going to hire people in this community. We want to be able to give more digital literacy in here," Banks says, noting that close 40 per cent of residents in East Harlem don't have access to broadband internet.

"I had a 15-year-old young person come to me and say 'I don't have a computer at home and we don't have broadband. I'm falling behind because those who have those things are no smarter, but they just have the tools to get it done.' So that's why this is so vital."

What's next for mesh

NYC Mesh currently has two supernodes and estimates that with about a dozen more it could blanket the entire city with wireless internet.

Growth is ramping up and more users means more funding, but it's still a volunteer-driven organization — something that may have to change as it scales up.

There's also debate in the community about whether to start charging more for the service as more users join the network.

But Giles says his group is a return to the original idea of what the internet was supposed to be, free and accessible to all.

"I would think it's actually actually how it used to be - we are going back to simpler time. It looks complicated, lots of wires, but it's simple."

• Watch Steven D'Souza's feature on NYC Mesh on Wednesday night's The National on CBC television and streamed online

Amazon.com Inc. is offering to pass along the discounts it gets on credit-card fees to other retailers if they use its online payments service, according to people with knowledge of the matter, in a new threat to PayPal Holdings Inc. and card-issuing banks. 

The move shows Amazon is willing to sacrifice the profitability of its payments system to spread its use. Swipe fees are a $90 billion-a-year business for lenders such as JPMorgan Chase & Co. and Citigroup Inc., networks including Visa Inc. and Mastercard Inc., and payment processors like First Data Corp. and Stripe Inc., which pocket a fraction of every sale when shoppers swipe cards or click “buy now.”

The financial industry’s fees amount to about 2 percent of a typical credit-card transaction, or 24 cents for debit. But big stores such as Amazon and Walmart Inc. have long been able to negotiate lower rates for themselves based on their massive sales volume. Now, Amazon is offering to pass its discount along to at least some smaller merchants if they agree to embrace its Amazon Pay service, said the people, who asked not to be identified because they aren’t authorized to discuss the plan publicly.

Shares of PayPal dropped 4.1 percent Wednesday, the most since Feb. 8. Mobile payments company Square Inc. erased most of its 3.7 percent gain from earlier in the day, leaving the stock up less than 1 percent. Visa fell 0.9 percent.

An Amazon spokeswoman declined to comment. It couldn’t be determined how many retailers have received Amazon’s offer for discounts. The company typically tests such initiatives before rolling them out broadly.

Previously, online merchants using Amazon’s service have paid about 2.9 percent of each credit-card transaction plus 30 cents, which is divvied up among Amazon, card issuers and payment networks. As part of its experiment, Amazon is offering to negotiate lower fees with merchants making long-term commitments to use the service, according to one person familiar with the matter.

Amazon is able to export the rates it has negotiated with banks and payment networks because, like PayPal, it’s acting as a so-called payments facilitator. That means it aggregates smaller merchants to help them reduce the cost of accepting electronic payments.

Gaining Traction

Amazon Pay, which has attracted more than 30 million users since the company revived it in 2013, lets online shoppers log into their Amazon accounts from other websites, enabling them to complete the transaction using credit cards and delivery addresses already stored rather than having to enter them again. For Amazon, that means drawing additional revenue from e-commerce sales on other sites.

The service mostly appeals to smaller merchants who benefit from the trust shoppers place in Amazon, as well as minimizing the data entry required to complete a mobile transaction. Customers include Gogo Inc., which provides in-flight internet access.

Merchants aren’t eager, however, to share too much information with Amazon, which may compete with them to sell similar products on its own site. Amazon dominates the U.S. e-commerce market, with 43.5 percent of all sales in 2017, according to EMarketer Inc. PayPal has emphasized its status as a non-retail competitor to differentiate itself.

Amazon Pay is among many products the company offers to get a piece of other retailers’ e-commerce revenue. Merchants selling goods on their own websites can let Amazon handle warehousing, packing and shipping for a fee. Many find it cheaper to pay Amazon for logistics than do it on their own because they benefit from Amazon’s volume shipping discounts.

Single Button

Amazon’s move is part of an escalating battle in the U.S. between traditional financial firms and technology giants to develop a dominant digital payments system -- akin to what Jack Ma’s Alipay and Tencent Holdings Ltd.’s WeChat Pay have achieved in China.

Last month, Visa and Mastercard said they’re teaming up on their own combined online checkout button, abandoning their separate Visa Checkout and Masterpass initiatives. For its part, Visa is betting there will be just one button at the online checkout in the future, Chief Executive Officer Al Kelly said on a conference call with analysts last month. 

Read more: Shiny new button may help Visa, Mastercard fight PayPal

The networks’ joint effort has been seen as a challenge to Amazon Pay, as well as to PayPal, which is considered the U.S. leader in digital wallets with 237 million global accounts.

“There’s way too much clutter in the e-commerce checkout environment, and it’s just not good for users, and it’s not good for merchants,” Kelly said. The ultimate future, he said, is “a single button, which is much more analogous to the situation that you see in the physical world where there’s a single terminal and all products run through that terminal.”