m0dest

Yeah, I left as soon as I saw the font.

They will also repair by mail.

unfortunately, no carrier will do this. I suspect that this is because of administrative fees associated with simply allocating a phone number and the network overhead from having a device associate with cell towers when idle.

>A still image file containing one frame of a video codec has been long theorized

The I-frame encoding in MPEG-1 was basically identical to baseline JPEG. The compressed frames can be losslessly converted to JPEG and vice-versa. So, in a sense, we were already there.

Reusing the I-frame compression from a video codec is the only strategy that makes sense for a lossy still image codec. Video codecs are where the major innovation is happening, with wide participation from every player in the industry, and a large part of the innovation has been around improving I-frame efficiency. They're being hardware optimized and baked into software implementations. And even when patents are involved, still image codecs are usually able to piggyback on the video codec licenses that are already on the device.

So, per-device licenses. This is dead on arrival.

Decades from now, the story of IPv6 will be a cautionary tale about the danger of ignoring incentives when enhancing open standards.

So much of the spec seems to have been designed in an idealist vacuum that the promoters are blind to its own failures. The addresses are ugly and impossible to memorize but that shouldn't matter because... There are no performance advantages but that was out of scope because... There are few security advantages because that wasn't a core goal because...

I'm not saying that we should give up on IPv6. But we should acknowledge that its slow adoption is entirely due to a standard that was poorly designed for the real needs of critical stakeholders and poorly marketed to everyone else.

at this point, Apple would _pay you_ to use it if they thought it would help adoption. MapKit usage outside of iOS is a critical to the success of Apple Maps.

long term, I wouldn't be surprised if maps.apple.com gained a web experience, too

I worked from home for 2 years in the same situation (single, no dependents). It was actually great for me socially. Commuting can be so draining. Instead of arriving home exhausted at 7 PM, I would be ready to go out right at 5 PM. I'd do laundry and clean up my place during breaks in the day, so I had even more time free in the evenings and weekends.

To take advantage of it, you do have to be super proactive about filling your social calendar in the evenings. But that's true in any situation.

Copy pasta.

I have started to think that parts of GDPR should have been restricted to large companies - e.g. anyone with more than 100k active users, data describing 100k individuals, or an organization employing more than 100 employees. That would seem like a fair way to protect privacy while keeping barriers low for tech ventures / experiments.

It seems like a poor branding decision to name the app after the rather awkward domain name ("Hummi.nz"). As a mobile-first app, you aren't constrained by domain names, so you have better options.

Apple did not "disable" Cut.

1. Copy the source file with Cmd-C

2. Browse to the destination

3. Move with Cmd-Opt-V

It's a UI design decision to avoid Cut in the filesystem. Cut would behave differently from Cut in every other app -- namely, the file is not deleted immediately after Cut. It seems better to avoid calling this "Cut" than to have it behave inconsistently from other apps.

Me too.

They're recovering Magnetic Scrolls from some actual magnetic scrolls. There's something beautifully poetic there.

Those Piperchat guys are onto something!

This was announced 72 hours after Trump was elected... a president who vocally opposes net neutrality.

http://about.att.com/story/att_introduces_stream_saver.html

Note that this is categorically worse than the T-Mobile deal. Unlike T-Mobile Binge On, this throttled data still counts against your data quota. Users get nothing in exchange. It's forcing a quality limit setting (one that most mobile video apps already provide) and making it difficult to disable.

To evoke maximum outrage, you should show AdMob mobile banner ads on the Touch Bar. First app to do it wins a free press cycle.

Widevine (Google) and PlayReady (Microsoft) are the top EME DRM providers. Google and Microsoft are both on the EME working group.

The critical question is whether rightsholders can use the DMCA (or local equivalent) to sue someone for circumventing DRM technology that isn't their own.

If not, if the only party capable of enforcing anticircumvention is the DRM vendor itself, then this could be very effective.

The key innovation in Windows Phone's "Continuum" feature is that the desktop is just another view into the phone. You can access the same exact apps and user data - browser, mail, calendar, messaging, etc. - and switch back and forth without losing state. In that world, a phone with KVM support doesn't just save you from owning a PC; it saves you from having to keep track of a different set of installed apps, setting up accounts, preferences, and state (currently open tabs, documents, etc.)

I'd welcome something like that for Android, especially as Google is experimenting with support for windowed Android apps with mouse support.

Unfortunately, Maru is not that. It appears to only run X11 apps on the desktop, and only Android apps on the phone. I don't think there's enough value in that. It has the inconveniences of needing to dock/undock your phone plus all of the hassle of having to maintain 2 separate sets of apps, settings, and state.

I'm so happy to see arguments specified with "-" and "--" (UNIX-style) instead of "/" (DOS-style).

The DOS-style CLI arguments used by Microsoft's other command line tools seem like such a stubborn throwback to a long-lost war. "/" won the battle for folder path separators (see: URLs) and "-" won the battle for argument delimiters.

Lack of screenshots is usually a red flag; you guys should fix that :)

I'd really love it if you repeated the same tests for Bing, just to get coverage. (Yahoo/Baidu would be the other big two.) Historically, Bing hasn't used fully functional headless browsers to crawl, which has limited its ability to index dynamic content like this.

Google has "only" 70% market share, so it seems irresponsible to make engineering decisions without testing the others. Google+Bing+Yahoo+Baidu get you to 98%.

Interesting naming. The WYSIWYG rich text editor in Google Docs is named Kix. The engine behind Google Sheets is named Trix.

It sounds like:

• Docker is really cool! Everyone is talking about Docker!

• We at Microsoft like Docker, too! (But Docker obviously screws us pretty hard, since the whole ecosystem is built around the Linux kernel. Windows isn't great at this type of isolation.)

• We don't like being left out of the Docker container party, so we're going to create _two_ things that are Almost As Good As Docker Containers!

• (1) A new package format, "Windows Server Containers," that we're calling a container, even though it doesn't actually offer containment. Containers can mess with other containers.

• (2) The same old Windows Server virtual machines, but we're going to call them "Hyper-V Containers." Yeah, they're just VMs. Separate kernels in memory and all of that.

• We know neither of these offer what you wanted. But good news! You can use the same container format for _both_ of these new almost-a-container systems.

Yikes.

Look into commercial book scanners that use vacuums. This is a solved problem. Kirtas is one of those manufacturers.

https://www.youtube.com/watch?v=ds63ZBXFdLM http://www.kirtas.com/

50 pages per hour with no damage to the books.

You're looking at $50k-$90k for the equipment plus $8k/year service contract, though. So you need to figure out whether book scanning is something that the Internet Archive is interested in, beyond this project.

It's interesting because handwritten notes are seen as one of the last symbols of human authenticity. The unique drawing of each letter seems to prove that a human invested time and thought in directly communicating with you. There was no copy-paste. There was no form letter. This was not a bot. And, based on the length of the note, there was provable effort involved. Both a Turing test and a proof of work problem. The world's oldest Captcha.

And so begins the devaluing of that proof. Just like when marketers started reproducing the "signature" on every sales letter with blue-colored toner, mimicking the authenticity of a hand signature.

I don't write handwritten letters, and I don't romanticize the past. But our dwindling ability to assess the authenticity of incoming communication is slightly unsettling.

When a GUI app doesn't show any screenshots along the way from the homepage to the download link, you can usually assume the worst. (Not true on GitHub, though.)

Should rename to "diff two HTTP(S) responses" instead of requests.

I understand that you can sniff IMSI without being a recognized carrier. But to actually get a cell phone to join your tower – don't you need the carrier's keys to be able to authenticate during the tower handshake? (iOS 5+ warns about unencrypted tower connections, so presumably these have to be authenticated UMTS?)

If so, should we expect that the carriers surrendered their keys to law enforcement to allow them to run fake cell towers that authentically emulate their networks?

Agree, this is super strange. No one wants to use DHE because of the performance impact.

Windows 7 and later do already support ECDHE + GCM, but only when combined with ECDSA. In practice, nobody can use ECDSA because old clients still need RSA certificates.

So we continue to wait for TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which is clearly the cipher suite that everyone wants. Years later, still not available for Windows Server.