5 stories
1 follower

Credit Card Rewards

4 Comments and 8 Shares
I should make a list of all the things I could be trying to optimize, prioritized by ... well, I guess there are a few different variables I could use. I'll create a spreadsheet ...
Read the whole story
264 days ago
It's nice to be understood.
Share this story
3 public comments
247 days ago
I should make a list of all the things I could be trying to optimize, prioritized by ... well, I guess there are a few different variables I could use. I'll create a spreadsheet ...
264 days ago
That last frame...
New York, NY
265 days ago
I'm currently on Charles Schwab's High Yield Investing AMEX card, which is just 1% on everything, but I hear the Uber credit card launching next week is great. I also use Amazon's card for Amazon purchases (5%).

I'm pretty sure most places won't let you have more than 5 cards, which btw, is too many.
265 days ago
Citi Double Cash is 2% back on everything, and it's a MasterCard, so it's actually accepted everywhere.
264 days ago
I use the doublecash MasterCard for everything I can, and the Amazon card for Amazon/Costco (it's a visa). I don't spend enough at Costco to make Costco's visa worth the hassle.
264 days ago
this thread, after this comic... 😂😂😂

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

1 Comment and 2 Shares

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.

Philips BDM4350UC
Panel 43" IPS
Resolution 3840 × 2160
Refresh Rate 60 Hz
Response Time 5 ms gray-to-gray
Brightness 300 cd/m²
Contrast 1200:1
Viewing Angles 178°/178° horizontal/vertical
Color Saturation 1.07 billion colours, 100% sRGB
Pixel Pitch 0.2451 mm
Pixel Density 102 ppi
Brightness Uniformity 96 - 105%
Picture-in-Picture Up to four 1080p PiP images supported
Inputs 1 × D-Sub
2 × HDMI 2.0
2 × MHL
1 × DP 1.2
USB Hub 4-port USB 3.0 hub,
one port supports fast charging
Audio 7W × 2
Launch Price $799.99

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.

Read the whole story
793 days ago
A little bigger than would be ideal, but seems pretty good. An adjustable VESA mount would improve it.
Share this story

Zeiss Smart Optics: Discreet Smart Glasses

1 Comment

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.

Read the whole story
923 days ago
Zeiss (known for their camera lenses) has designed a optical system for projecting light into eyes from a pair of glasses in a much more subtle way than Glass. Very cool!
Share this story

Smaller Docker containers for Go apps

1 Share

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

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
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

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
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.


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!

Read the whole story
1077 days ago
Share this story

Seizing data for 2.5 years amounts to “general warrant,” court says

1 Comment

A federal appeals court has reversed an accountant's tax-evasion conviction because the government seized sized his computer data and held it for more than 2.5 years—a breach of the constitutional right to be free from unreasonable searches.

The 2nd US Circuit Court of Appeals ruled last week that the government's tactics against the Connecticut accountant amounted to an "unreasonable seizure." The authorities seized the accountant's records while investigating alleged illegal activity of his clients. But they continued holding the data for years and later brought charges against the accountant, who was not the target of the original investigation.

"If the government could seize and retain non-responsive electronic records indefinitely, so it could search them whenever it later developed probable cause, every warrant to search for particular electronic data would become, in essence, a general warrant," Judge Denny Chin wrote for the appeals court.

Read 4 remaining paragraphs | Comments

Read the whole story
1486 days ago
Using previously seized data to prosecute a different crime ruled unconstitutional. Impact on NSA?
Share this story