urlgrey

in 1997 I saw Linus Torvalds speak at UC Berkeley following his move to California to work at Transmeta. I was a computer science undergrad at UC Davis, and took Amtrak to Berkeley along with some friends to see Linus in person. Linux was building momentum, and Linus was a real celebrity to those in the space.

Supporting Linus and the Linux community is a great legacy for Transmeta, even if their products didn't find commercial success.

Another important feature: HEVC playback on Mac OS X. An increasing amount of video content, especially content recorded on mobile phones, uses HEVC. Inconsistent playback support represents a real barrier to HEVC adoption (among other things), and Firefox support goes a long ways toward making HEVC more widespread.

There are several options from Amazon, try searching for "Clip-on Ferrite Ring".

Author here, would love to discuss!

I'm amazed that their architecture doesn't include a CDN. These days I expect nearly all high traffic websites to make use of a CDN for all kinds of content, even content that's not cached.

They cited Cloudflare not being used due to privacy concerns. It'd be interesting to hear more about that, as well as why other CDNs weren't worth evaluating too.

This literally cost me sleep last night, paging me for new Kubernetes nodes that failed to transition to 'Ready' because they were unable to pull Calico images during bootstrapping. After some duct-taping to get those initial nodes up and running, we just moved the Quay-hosted images to a GCR repository and moved on with life.

But that doesn't diminish the fact that this outage is a complete disaster for Quay.

At Mux we use Cedexis Openmix to dynamically select between Fastly and Highwinds (now Stackpath) CDNs to stream a lot of video. The end-user experience with a CDN is going to vary dramatically depending on where your users are located around the world, which ISP they use, and many other factors that change by the minute. I wrote a blog[1] post about how & why we use multiple CDNs with our video service.

You might also want to evaluate a video QoE service to see what your users are experiencing in terms of video start-up times, rendition switching, buffering, etc.

[1] https://mux.com/blog/multi-cdn-support-in-mux-video-for-impr...

As of 2012, videos that didn’t load in two seconds had little hope of going viral.

This finding aligns with the results of a survey of users of the Mux video analytics service. We asked them "Which of the following streaming video problems is the most frustrating for you when it occurs?" Video rebuffering or stalled playback was considered the most annoying problem for 47% of respondents; video picture quality was chosen by only 14.3%. Slow startup times and rebuffering have a huge impact on the perceived QoE compared to video picture quality.

https://mux.com/blog/rebuffering-the-most-frustrating-and-fr...

Very short segment durations are effective only when latency is more important than quality.

Each TS segment must start with a key-frame, and the GOP size can't exceed the duration of a segment (e.g. one second). Lowering the segment duration increases the frequency of key-frames, which has the effect of lowering the quality you can achieve at a given bitrate.

Periscope developed a Low-Latency HTTP Live Streaming (LHLS) technique that relies on HTTP chunked transfer-encoding to stream video bytes as they are encoded at the origin. This is still subject to TCP packet retransmission overhead, but the time-to-first-byte is reduced significantly and leads to less buffering on the client.

Here's a Periscope post about LHLS: https://medium.com/@periscopecode/introducing-lhls-media-str...

Most systems that serve HLS media use fixed content-length segments, which requires knowledge of the length of a segment before the first byte can be sent over the wire. So, for a 5 second segment you would need to encode the entire 5 seconds before the first byte can be sent; this does not apply when streaming the segments with chunked transfer encoding.

Incidentally, at Mux we also use chunked transfer-encoding to stream video that is encoded on-the-fly with great performance.

The breach notice indicates that hashed passwords were compromised but doesn't mention whether a salt was used when computing the hashes.

Use of a salt makes all the difference, guarding against the use of rainbow tables to look up precomputed hashes of common passwords.

Watch the "Pentagon Wars - Bradley Fighting Vehicle Evolution" video: https://youtu.be/aXQ2lO3ieBA

It's a great example of how trying to design a product that works well for every stakeholder in every scenario leads to a Frankenstein of a product that doesn't work well for anybody. This happens all too often in government (typically military) contracts.

Crawlers & scrapers that rely on headless browsers like Chrome often initiate playback of video on the pages they access.

The company I work for (Mux) has a product that collects user-experience metrics for video playback in browsers & native apps. It's been a non-trivial effort developing a system to identify video views from headless browsers so that we might limit their impact on metrics. Being able to make this differentiation has a real benefit to human users of our customer's websites.

My preference would be for headless browsers to not interact with web video or be easily identifiable via request headers, though I doubt either of these things will happen any time soon.

Great question! There was a fairly even distribution of slow-performing requests across the many user-agent strings coming from the Facebook ASN.

My hunch is that the Facebook crawlers send user-agent strings that Facebook has seen in requests to their own services. This allows them to crawl content in linked posts masquerading as a device that their users would actually use.

Post author here: this post was written in June 2017, and the subject has become increasingly relevant since the MySpace video advertising bot fraud reported by BuzzFeed on October 27, 2017: https://www.buzzfeed.com/craigsilverman/remember-tom

The USDA partnered with industry to develop a process for increasing Vitamin D levels in mushrooms by simply exposing them to ultraviolet light.

Monterey Mushrooms has a video showing how this step was added to the packaging process:

http://www.montereymushrooms.com/nutrition/mushrooms-with-vi...

Two years ago I integrated CoderPad into a technical-screening-as-a-service product I was involved with; Vincent's responsiveness and focus were very impressive. I'm thrilled to see him making such progress!

In the event that someone else is looking to integrate CoderPad into their product, here's the Java client library I wrote for CoderPad in 2015: https://github.com/skidder/coderpad-java-api

Crawlers & bots trigger video playback on the websites they visit, though it's probably unintentional in most cases. At Mux we have taken steps to identify such video views to limit their impact on aggregate video view performance metrics: https://mux.com/blog/do-androids-watch-videos-of-electric-sh...

Mux (https://mux.com/) collects performance metrics for video delivery & playback on the websites & apps of our customers. These metrics feed into our real-time alerting system. If the error-rate for a customer property (site) or video-title is exceptionally high then an alert will be triggered. Mux customers can configure alert notifications to be sent to Slack & email, and view a history of alerts in the Mux web dashboard. We also offer the ability to view breakdowns of playback failures, video start-up times, and more through our dashboard. This can be helpful for diagnosing playback issues related to specific browsers, geographies, ISPs, and more.

Sure! We evaluated several anomaly-detection tools & libraries. They included:

tried-and-true statistical methods like probability density functions

Yahoo EGADS anomaly-detection library

Numenta HTM neural-network anomaly-detection library

We ruled out HTM due to AGPL licensing concerns. It's an interesting product, but wasn't a good fit for us at this point in time. EGADS and other basic statistical methods can actually get you pretty far.

I highly recommend reading Tyler Akidau's article titled "The world beyond batch: Streaming 101": https://www.oreilly.com/ideas/the-world-beyond-batch-streami...

And its follow-up post: https://www.oreilly.com/ideas/the-world-beyond-batch-streami...

Handling failure in a distributed stream processing system is challenging, but Flink removes a lot of this complexity from the job of the application developer.

A high-availability Flink cluster will often use an Apache Zookeeper cluster to elect a leader Job Manager (coordinator) instance. One or more Task Managers (the systems that actually execute the pieces of a Flink application) discover the current Job Manager leader by querying Zookeeper.

Zookeeper tracks the current leader and running jobs. State for those jobs is written periodically to external storage, often an HDFS cluster. Flink automatic-checkpointing will write application state at fixed intervals to storage and, in the event of a failure, automatically resume from the most recent checkpoint. There's also support for manual savepoints which can be used to restore state when submitting a new job or resuming from catastrophic failure.

Flink provides exactly-once guarantees within the context of the Flink application; any side-effects of your application, such as calls to external services or records written to a database, can happen multiple times if you're recovering from a failure.

Great suggestion! We'll have a follow-up post soon that goes into greater detail on the mechanics of how Mux uses Flink.

I'm the author of this Mux blog post and would love to take any questions or comments, as well as suggestions for future posts. Thank you for your interest!

A Yaesu VX8GR handheld HAM radio transceiver is my spare. I carry it in my work bag every day, along with a quarter-wave antenna, spare battery and a AA-battery adapter. It'll run for days as a receiver and can transmit at 5 watts - plenty of power to hit a repeater within earshot of someone who can call for help on my behalf. Although I work in a dense city, I'm not under the illusion that cell-phone infrastructure will be available for long after a major disaster, particularly an earthquake.

HAM radios are also very useful when venturing into the wilderness. Many hikers monitor the 2m/1.44m calling frequencies periodically for distress calls. And at the right altitude your meager 5 watts can cover tremendous distances.

What a wonderful story! The friend in the story began to remind me of the character Emmet from The Lego Movie: an oddball whose quirks ultimately make him a hero.

The counties included on the board appears heavily editorialized; the Association of Bay Area Governments (ABAG) includes Sonoma, Napa, and Solano counties which are not shown (http://abag.ca.gov/overview/members.html).

It's interesting that a low occurrence of unique words in a story can be an indication of a lie. Does that position people speaking a secondary language in an unavoidable place of distrust? Beyond body language, it's just more difficult to tell if someone's story lacks richness because they're not telling the truth, or they're simply not comfortable with the language and have a small vocabulary to draw upon.

No offense taken; I too do not trust US law enforcement to use this technology in a manner that respects the privacy and rights of law-abiding citizens.

Nonetheless, it is a fact that this technology has been used to trace the location of people responsible for the placement of roadside bombs in warzones abroad, and has been used to locate the headquarters of an organized crime group in Juarez, Mexico, a place that averaged 8.5 killings per day in 2010.

I highly recommend listening to the Radiolab story, it raises some interesting points.

I recommend listening to the 'Eye in the Sky' episode of of Radiolab: http://www.radiolab.org/story/eye-sky/

It features an interview with Ross McNutt, also interviewed in the Washington Post story. McNutt describes aerial surveillance technology he developed for the US military operations in Iraq & Afghanistan, in use for over 10 years. The primary reason for not introducing it here is the US is opposition from privacy groups, despite having been used successfully abroad to counter terrorism and organized crime.