Enlarge / A Comcast service van in October 2014. (credit: Mike Mozart / Flickr)

Comcast is doubling download speeds and increasing upload speeds for the $10-per-month Internet Essentials plan that it sells to low-income subscribers.

Comcast had faced criticism for keeping the plan's speeds at 25Mbps down and 3Mbps up during the pandemic, though even those speeds were an increase from the 15Mbps/2Mbps offered until March 2020. In today's announcement, Comcast said it is "doubling the program's Internet download speed to 50Mbps and increasing the upstream speed to 5Mbps for all new and existing customers at no additional cost."

The speed upgrade "will be rolled out nationally beginning March 1," Comcast said.

Low-income users still face Comcast's 1.2TB data cap, which adds $10 to a monthly bill for each additional block of 50GB. But data-cap overage charges are capped at $30 per month for Internet Essentials subscribers, while the extra charges can go up to $100 for other customers.

Information on how to qualify for Internet Essentials is available here.

Students complained about low speeds

Although former Federal Communications Commission Chairman Ajit Pai still insists that 25Mbps/3Mbps speeds are good enough for US home-Internet users, at least some customers of Comcast's Internet Essentials don't agree.

"As remote learning dragged on through 2020, the coronavirus pandemic pitted Comcast against an unlikely opponent: a group of teenagers," BuzzFeed wrote last week. "Since last spring, Baltimore-based student activists have been waging a campaign for faster Internet speeds and arguing that the telecom behemoth's Wi-Fi offering for low-income households, Internet Essentials, isn't always fast enough for successful distance learning."

In a family with multiple kids doing remote learning, the 3Mbps upload speeds can be a problem. High school senior Kimberly Vasquez "said it's normal for her to refresh the page several times before she can even enter the Zoom," according to BuzzFeed. "Once she's in, she frequently gets kicked out because of slow speeds." The student told BuzzFeed she "had to talk to my teachers about my Wi-Fi situation and making sure I'm not being penalized for it."

City councilors in Baltimore, Philadelphia, and Detroit also called on Comcast to boost speeds for the low-income plan last summer, the Baltimore Business Journal reported at the time.

More pressure came from former Comcast sales agent Chase Roper, who tweeted on January 11 that he "just quit working for Xfinity/Comcast" and wants families to know that Internet Essentials does not offer "adequate speed for children to do their live 'Zoom' online class work." He followed that up with a blog post in which he asked, "How can students be expected to learn equally in this situation when some families are able to pay for multiple 1,000Mbps Internet accounts at one address for each of their students while others cannot afford even the minimum upload speed that actually works well from the one provider available to them? Why remove all data caps and over-charges at the beginning of the pandemic but when the next remote school year starts up, continue the data cap and extra charge policy?"

Comcast defends low-income program

Comcast began Internet Essentials about 10 years ago to secure government approval of its acquisition of NBCUniversal, and it continued the program after the merger condition expired in 2014. Comcast defended its handling of the program in its speed-upgrade announcement today, calling Internet Essentials "the largest and most comprehensive low-cost Internet adoption program for low-income Americans."

The new speed increase "is the sixth time in 10 years that Comcast has increased broadband speeds for Internet Essentials customers while keeping the cost of the service at $9.95 a month," the company said. Since the pandemic began, Comcast has been offering two months free to new Internet Essentials customers and said it is keeping that deal open until June 30, 2021.

Comcast earned praise from consumer advocates early in the pandemic when it first offered the two free months and boosted Internet Essentials speeds to 25Mbps/3Mbps. But Comcast courted controversy again this month by expanding its data cap to all parts of its territory that weren't previously capped. Comcast later agreed to delay data-cap enforcement in newly capped areas until August 2021 after pressure from lawmakers, including a group of Massachusetts legislators who are trying to ban data caps for the remainder of the pandemic.

Read Comments

CBS has made the entirety of the first episode of its new series Star Trek: Picard freely and publicly available as a YouTube video. This is an opportunity for viewers curious about the show to see if Picard is worth subscribing to the network's streaming service, CBS All Access, to watch the rest of the series.

The episode on YouTube is the same as the pilot episode that premiered on CBS All Access last week. The second episode of Picard began streaming on CBS All Access yesterday, and the network plans to release episodes at a weekly cadence. CBS has not said whether it plans to make other episodes available for free on YouTube in the future, but it seems likely.

The description for the video says the episode will only be available "for a limited time" and that it's presented by Geico. It does not, however, clarify how long "a limited time" is or when the video might become unavailable.

Picard has received generally positive critical reviews to date, but it's early days for the series. The show takes place 20 years after 2002's Star Trek: Nemesis, which was the last time actor Patrick Stewart appeared on screen as Picard in a live-action Star Trek production. It has already included some cameos from actors and characters from The Next Generation-era Star Trek. Stewart, who is also an executive producer on Picard, recently said that it's his goal to see all the principal characters of The Next Generation in Picard before the series ends its run.

The series has also been renewed for a second season, set to premiere in 2021. CBS plans to bring back Star Trek: Discovery for a third season with a new showrunner, and it has plans for additional series set in the Star Trek universe, including one focused on Michelle Yeoh reprising her role as Philippa Georgiou from Discovery.

We've embedded the full episode of Picard above.

Read Comments

For many workloads that require a lot of on-screen space, big displays are hugely beneficial — the bigger the better. TPV Technology, the company that produces monitors under Philips brand, recently decided to go very big and introduced a new 43" display with a 3840 x 2160 resolution. While the monitor is intended mostly for prosumer workloads, its price is not too high.

Extremely large displays are generally overkill for everyday workloads, but there are industries where the workloads require more on-screen space than a single monitor can provide. For example, many engineers and financial brokers use multi-display setups to maximize their productivity and view far more info than they could on a single display. While it is impractical to substitute four, six or eight displays in control rooms or in traders’ offices with fewer physical screens, engineers and designers could use one big monitor instead of two smaller ones. Philips is targeting this group of users with its Brilliance UltraClear 43” display, which is more like a television than a monitor.

The Philips UltraClear 43” (BDM4350UC) display uses an IPS panel with a 3840 × 2160 resolution and W-LED backlighting. It has a 300 nit brightness, a 1200:1 contrast ratio, and a 60 Hz refresh rate. According to Philips, the brightness uniformity is 96~105%, which is quite good for a display of this size. Philips also includes a uniformity feature called Smart Uniformity to correct inconsistencies in the backlighting, but it's not clear how well it works in the real world or what limitations it imposes on the display modes that can be used.

The UltraClear 43” comes with two HDMI 2.0 ports with MHL support, two DisplayPort 1.2 ports, and a D-Sub connector. The monitor can be connected to up to four video sources and display images from them in picture-by-picture mode. The display is also equipped with a quad-port USB 3.0 hub as well as two 7W speakers.

Just like TVs, the Philips UltraClear 43” comes with a stand that does not allow adjustment of tilt or height, which is a drawback. Fortunately, the monitor has a VESA mount, so, it should be possible to get an appropriate arm or aftermarket stand that does support this, although it will need to be able to support the display's mass and size.

It remains to be seen whether there's a sizable market for the UltraClear 43”, but for tasks like editing spreadsheets and CAD work it could be quite useful. Right now the Philips UltraClear 43” is available on Amazon for $799.99.

Gallery: Philips Begins to Sell 43” 4K IPS Display for $799

With Google Glass, one of the major barriers to adoption was just how glaringly obvious it was that you were wearing Google Glass. The display was a field sequential color LCoS with a simple projection system to make the display visible at a short distance away from the eye. Unfortunately, the problem with this system was that the display was completely obvious and wasn’t really integrated into traditional thin lens glasses. It was also pretty obvious when the display was active, as you could see light coming out of the LCoS array without getting uncomfortably close to the person wearing Glass.

Some of the other systems I’ve seen for projecting a display for smart glasses have also been pretty obvious to spot such as any of ODG’s smart glasses, although those aren’t really designed to be subtle in any way as they try to pack a full tablet of hardware into something head-worn. Sony’s SmartEyeGlass gets closer to something subtle, but it’s still glaringly obvious that you’re wearing something odd.

Zeiss identified this as an issue, and in response they created an internal team to try and make an optical system that resolves all of these issues. Their solution is what they’re now calling Smart Optics. This optical system takes a display mounted at the edge of the lens and can project it directly into the eye at an arbitrary position on the lens, with an arbitrary focus to either place the displayed image a short distance away from the eye (~2m), or even at infinity to create a true HUD.

In essence, this optical system relies upon total internal reflection and a Fresnel structure to transmit the light from the display through the lens into the eye. A complex prism design reflects the light from the display at the edge of the display into the lens, where the Fresnel structure then reflects the light in the lens out into the eye. The Fresnel structure is index-matched with the lens itself, which makes it almost invisible to the eye unless you have the right lighting to highlight the structure.

The entire design is made from injection-molded polycarbonate, which means that it’s capable of being mass-produced in a method similar to most current glasses. Based on discussions with those that worked on this project, the prism in particular was especially difficult to create as its shape is complex and voids and other defects would appear in the polycarbonate as it cooled. Zeiss also emphasized that their design was covered with over 250 patents to drive home the difficulty of making this optical system work.

Zeiss showed off an early prototype, which even at this stage was impressive as there was no visible translucency that could occlude vision and the projection worked flawlessly. Unfortunately, as the design is supposed to be made with a prescription for those that need one I couldn’t quite get the full experience as the corrective lenses that they had for the prototype weren’t quite strong enough for my eyes, but their rapid prototyping rig worked well and showed acceptable resolution and luminance.

I wasn’t really able to get much in the way of details regarding whether any devices with this optical system were imminent, but it sounds like Zeiss is working with partners that can put their optics to use. Based upon a lot of the discussions I’ve had with various people working with wearables it sounded like smart glasses were at least 5-10 years out, but with technologies like this I wouldn’t be too surprised to know that by the 7nm node that smart glasses using this technology will start to reach mass consumer adoption.

At litl we use Docker images to package and deploy our Room for More services, using our Galaxy deployment platform. This week I spent some time looking into how we might reduce the size of our images and speed up container deployments.

Most of our services are in Go, and thanks to the fact that compiled Go binaries are mostly-statically linked by default, it’s possible to create containers with very few files within. It’s surely possible to use these techniques to create tighter containers for other languages that need more runtime support, but for this post I’m only focusing on Go apps.

The old way

We built images in a very traditional way, using a base image built on top of Ubuntu with Go 1.4.2 installed. For my examples I’ll use something similar.

Here’s a Dockerfile:

FROM golang:1.4.2
EXPOSE 1717

RUN go get github.com/joeshaw/qotd

# Don't run network servers as root in Docker
USER nobody

CMD qotd

The golang:1.4.2 base image is built on top of Debian Jessie. Let’s build this bad boy and see how big it is.

$ docker build -t qotd .
...
Successfully built ae761b93e656

$ docker images qotd
REPOSITORY     TAG         IMAGE ID          CREATED           VIRTUAL SIZE
qotd           latest      ae761b93e656      3 minutes ago     520.3 MB

Yikes. Half a gigabyte. Ok, what leads us to a container this size?

$ docker history qotd
IMAGE               CREATED BY                                      SIZE
ae761b93e656        /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "qotd"]   0 B
b77d0ca3c501        /bin/sh -c #(nop) USER [nobody]                 0 B
a4b2a01d3e42        /bin/sh -c go get github.com/joeshaw/qotd       3.021 MB
c24802660bfa        /bin/sh -c #(nop) EXPOSE 1717/tcp               0 B
124e2127157f        /bin/sh -c #(nop) COPY file:56695ddefe9b0bd83   2.481 kB
69c177f0c117        /bin/sh -c #(nop) WORKDIR /go                   0 B
141b650c3281        /bin/sh -c #(nop) ENV PATH=/go/bin:/usr/src/g   0 B
8fb45e60e014        /bin/sh -c #(nop) ENV GOPATH=/go                0 B
63e9d2557cd7        /bin/sh -c mkdir -p /go/src /go/bin && chmod    0 B
b279b4aae826        /bin/sh -c #(nop) ENV PATH=/usr/src/go/bin:/u   0 B
d86979befb72        /bin/sh -c cd /usr/src/go/src && ./make.bash    97.4 MB
8ddc08289e1a        /bin/sh -c curl -sSL https://golang.org/dl/go   39.69 MB
8d38711ccc0d        /bin/sh -c #(nop) ENV GOLANG_VERSION=1.4.2      0 B
0f5121dd42a6        /bin/sh -c apt-get update && apt-get install    88.32 MB
607e965985c1        /bin/sh -c apt-get update && apt-get install    122.3 MB
1ff9f26f09fb        /bin/sh -c apt-get update && apt-get install    44.36 MB
9a61b6b1315e        /bin/sh -c #(nop) CMD ["/bin/bash"]             0 B
902b87aaaec9        /bin/sh -c #(nop) ADD file:e1dd18493a216ecd0c   125.2 MB

This is not a very lean container, with a lot of intermediate layers. To reduce the size of our containers, we did two additional steps:

(1) Every repo has a clean.sh script that is run inside the container after it is initially built. Here’s part of a script for one of our Ubuntu-based Go images:

apt-get purge -y software-properties-common byobu curl git htop man unzip vim \
python-dev python-pip python-virtualenv python-dev python-pip python-virtualenv \
python2.7 python2.7 libpython2.7-stdlib:amd64 libpython2.7-minimal:amd64 \
libgcc-4.8-dev:amd64 cpp-4.8 libruby1.9.1 perl-modules vim-runtime \
vim-common vim-tiny libpython3.4-stdlib:amd64 python3.4-minimal xkb-data \
xml-core libx11-data fonts-dejavu-core groff-base eject python3 locales \
python-software-properties supervisor git-core make wget cmake gcc bzr mercurial \
libglib2.0-0:amd64 libxml2:amd64

apt-get clean autoclean
apt-get autoremove -y

rm -rf /usr/local/go
rm -rf /usr/local/go1.*.linux-amd64.tar.gz
rm -rf /var/lib/{apt,dpkg,cache,log}/
rm -rf /var/{cache,log}

(2) We run Jason Wilder’s excellent docker-squash tool. It is especially helpful when combined with the clean.sh script above.

These steps are time intensive. Cleaning and squashing take minutes and dominate the overall build and deploy time.

In the end, we have built a mostly-statically linked Go binary sitting alongside an entire Debian or Ubuntu operating system. We can do better.

Separating containers for building and running

There have been a handful of good blog posts about how to do this in the past, including one by Atlassian this week. Here’s another one from Xebia, and another from Codeship.

However, all these posts focus on building a completely static Go binary. This means you eschew cgo by setting CGO_ENABLED=0 and the benefits that go along with it. On OS X, you lose access to the system’s SSL root CA certificates. On Linux, user.Current() from the os/user package no longer works. And in both cases you must use the Go DNS resolver rather than the one provided by the operating system. If you are not testing your application with CGO_ENABLED=0 prior to building a Docker container with it then you are not testing the code you ship.

We can use a few purpose-built base Docker images and the tricks from Jamie McCrindle’s Dockerception to build two separate Docker containers: one larger container to build our software and another smaller one to run it.

The builder

We create a Dockerfile.build, which is responsible for initializing the build environment and building the software:

FROM golang:1.4.2

RUN go get github.com/joeshaw/qotd
COPY / Dockerfile.run

# This command outputs a tarball which can be piped into
# `docker build -f Dockerfile.run -`
CMD tar -cf - -C / Dockerfile.run -C $GOPATH/bin qotd

This container, when run, will output a tarball to standard out, containing only our qotd binary and Dockerfile.run, used to build the runner.

Dynamically linked binary

Notice that we did not set CGO_ENABLED=0 here, so our binary is still dynamically linked against GNU libc:

$ ldd $GOPATH/bin/qotd
	linux-vdso.so.1 (0x00007ffea6b8a000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6e76e50000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6e76aa7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6e7706d000)

We need to run this binary in an environment that has glibc available to us. That means we cannot use stock BusyBox (which uses uClibc) or Alpine (which uses musl). However, the BusyBox distribution that ships with Ubuntu is linked against glibc, and that’ll be the foundation for our running container.

The busybox:ubuntu-14.04 image only has a root user, but you should never run network-facing servers as root, even in a container. Use my joeshaw/busybox-nonroot image — which adds a nobody user with UID 1 — instead.

The runner

Now we create a Dockerfile.run, which is responsible for creating the environment in which to run our app:

FROM joeshaw/busybox-nonroot
EXPOSE 1717

COPY qotd /bin/qotd

USER nobody
CMD qotd

Putting them together

First, create the builder image:

docker build -t qotd-builder -f Dockerfile.build .

Next, run the builder container, piping its output into the creation of the runner container:

docker run --rm qotd-builder | docker build -t qotd -f Dockerfile.run -

Now we have a qotd container which has the basic BusyBox environment, plus our qotd binary. The size?

$ docker images qotd
REPOSITORY     TAG         IMAGE ID          CREATED           VIRTUAL SIZE
qotd           latest      92e7def8f105      3 minutes ago     8.611 MB

Under 9 MB. Much improved. Better still, it doesn’t require squashing, which saves us a lot of time.

Conclusion

In this example, we were able to go from a 500 MB image built from golang:1.4.2 and containing a whole Debian installation down to a 9 MB image of just BusyBox and our binary. That’s a 98% reduction in size.

For one of our real services at litl, we reduced the image size from 300 MB (squashed) to 25 MB and the time to build and deploy the container from 8 minutes to 2. That time is now dominated by building the container and software, and not by cleaning and squashing the resulting image. We didn’t have to give up on using cgo and glibc, as some of its features are essential to us. If you’re using Docker to deploy services written in Go, this approach can save you a lot of time and disk space. Good luck!